VTY IPv6 ACLs in IOS-XR

One of the first things you have to do before adding IPv6 addresses in a router, is to protect its management plane. A simple way to implement a part of that is to define an ACL (Access List) under the relevant terminal lines (VTYs).

In IOS it's quite simple.
One ACL for IPv4 and one ACL for IPv6, which cannot share the same name.

! IOS
!----
ip access-list extended IPV4-VTY-ACL
 permit ip 10.0.0.0 0.0.0.255 any
 deny   ip any any log
!
ipv6 access-list IPV6-VTY-ACL
 permit ipv6 2001:DB8::/32 any
 deny   ipv6 any any log
!
line vty 0 10
 access-class IPV4-VTY-ACL in
 ipv6 access-class IPV6-VTY-ACL in
!

In IOS-XR it gets a little bit tricky.
One ACL for IPv4 and one ACL for IPv6, which must share the same name.

! IOS-XR
!-------
ipv4 access-list VTY-ACL
 10 permit ipv4 10.0.0.0 0.0.0.255 any
 20 deny   ipv4 any any log
!
ipv6 access-list VTY-ACL
 10 permit ipv6 2001:DB8::/32 any
 20 deny   ipv6 any any log
!
vty-pool default 0 10
line default
 access-class ingress VTY-ACL
!

Ok, then you think that this is good because it saves you typing.
So you expect to meet the same behavior when viewing the ACLs. Bad Luck. You still have to use the "ipv6" keyword in order to view the ipv6 ACL.

RP/0/RSP0/CPU0:ASR#sh access-lists VTY-ACL
ipv4 access-list VTY-ACL
 10 permit ipv4 10.0.0.0 0.0.0.255 any
 20 deny ipv4 any any log

RP/0/RSP0/CPU0:ASR#sh access-lists ipv4 VTY-ACL
ipv4 access-list VTY-ACL
 10 permit ipv4 10.0.0.0 0.0.0.255 any
 20 deny ipv4 any any log

RP/0/RSP0/CPU0:ASR#sh access-lists ipv6 VTY-ACL
ipv6 access-list VTY-ACL
 10 permit ipv6 2001:DB8::/32 any
 20 deny ipv6 any any log

Talking about uniformity...


Notes

IOS-XR offers a different way to protect the mgmt-plane by using the MPP feature (Management Plane Protection).

Sample IPv6 Addressing/Dimensioning Plan for ISPs

This is a high level summary of an IPv6 addressing & dimensioning plan for mid-sized service providers. Obviously it doesn't apply to all cases, but i hope other people will find it useful too.

First you define 3 levels of PoPs (Points of Presence), depending on number of customers and address consumption:

• Level-1 PoP (Large)
• Level-2 PoP (Medium)
• Level-3 PoP (Small)

Then you define 2 types of customers:

• Residential
• Business

General rules

• Keep the boundary on /32,/40,/48,/56,/64,/128 for easier management.
• Avoid hex letters (A,B,C,D,E,F) on infrastructure addresses, at least until you run out of numbers.
• Keep infrastructure addresses in a single block for easier ACL management.
• Loopbacks, Management, Internal can be contained in a single /41, leaving Public on the other /41. 
• Keep customer addresses in a single block per PoP for easier route aggregation.
• Too much aggregation won't help you much in case of multiple internet exits.

Each ISP gets at least a /32 from its RIR. A sample dimensioning could be the following:

1 x /32

• 1 x /40 : Infrastructure Addresses
• 1 x /48 for all PoPs : Loopbacks & Management
• 1 x /56 for all PoPs : Loopbacks
• 1 x /64 per Loopback Category
• 1 x /128 per Loopback Interface
• 1 x /56 per PoP : Management
• 1 x /64 per Management LAN
• 1 x /48 for all PoPs : Reserved
• 1 x /48 per PoP : Internal Networks
• X1 x /56 : Routers P2P Links
• 1 x /64 per Routers P2P Link 
• X2 x /56 : Routers LANs
• 1 x /64 per Routers LAN
• X3 x /56 : Hosts LANs
• 1 x /64 per Hosts LAN
• X4 x /56 : Servers LANs
• 1 x /64 per Servers LAN
• X5 x /56 : Other
• 1 x /64 per Other
• 1 x /48 per PoP : Public Networks
•  X1 x /56 : Routers P2P Links
• 1 x /64 per Routers P2P Link 
•  X2 x /56 : Routers LANs
• 1 x /64 per Routers LAN 
•  X3 x /56 : Hosts LANs
• 1 x /64 per Hosts LAN 
•  X4 x /56 : Servers LANs
• 1 x /64 per Servers LAN 
• X5 x /56 : Other
• 1 x /64 per Other
• A x /40 : Level-1 PoP Customers
• N1 x /40 per PoP : Business Customers
• 1 x /48 per Large Customer
• 1 x /56 per Small Customer
• N2 x /40 per PoP : Residential Customers
• 1 x /56 per Customer LAN
• 1 x /64 per Customer WAN
• B x /40 : Level-2 PoP Customers
•  M1 x /40 per PoP : Business Customers
•  1 x /48 per Large Customer
•  1 x /56 per Small Customer
•  M2 x /40 per PoP : Residential Customers
•  1 x /56 per Customer LAN
•  1 x /64 per Customer WAN
• C x /40 : Level-3 PoP Customers
•  L1 x /40 per PoP : Business Customers
•  1 x /48 per Large Customer
•  1 x /56 per Small Customer
•  L2 x /40 per PoP : Residential Customers
•  1 x /56 per Customer LAN
•  1 x /64 per Customer WAN
• D x /40 : Reserved

Calculations

A,B,C depend on the total number of /40 per type of PoP (A>B>C).
N1,N2,M1,M2,L1,L2 depend on the number of customers per type of PoP (N1>M1>L1 & N2>M2>L2)

The summary of (N1 x /40) + (N2 x /40) for all Level-1 PoPs equals to A x /40.
The summary of (M1 x /40) + (M2 x /40) for all Level-2 PoPs equals to B x /40.
The summary of (L1 x /40) + (L2 x /40) for all Level-3 PoPs equals to C x /40.

Notes

The above plan is based on what i believe to be current best practices and recommendations for a specific type of service provider. Some things will change, as they changed in the past:

1. Initially a /48 was recommended for all sites in the general case (RFC 3177), now it's per case (RFC 6177).
2. Some years ago a /127 was not recommended for p2p links (RFC 3627), now /127 came back into surface (RFC 6164).
3. Currently only /64 is used by SLAAC (RFC 4862), but someone though something longer would be better (draft-yhb-6man-slaac-improvement).

I am sure we'll see a lot of changes in the following months/years regarding the length of prefixes in IPv6. I just hope we don't have to move to something new with more than 128 bits.

IOS-XR still lacks proper help output

Is it really so hard for Cisco to put a logic in the list of available configuration commands?

This is what you get if you enter "?" under a BVI in an ASR9k running IOS-XR 4.0.1.

RP/0/RSP0/CPU0:ASR9k1(config-if)#?    
  address-family   AFI/SAFI configuration
  arp              Configure Address Resolution Protocol
  bandwidth        Set the bandwidth of an interface
  clear            Clear the uncommitted configuration
  commit           Commit the configuration changes to running
  crypto           Set crypto parameters
  dampening        configure state dampening on the given interface
  describe         Describe a command without taking real actions
  description      Set description for this interface
  do               Run an exec command
  exit             Exit from this submode
  frame-relay      Frame Relay interface configuration commands
  ipv4             IPv4 interface subcommands
  load-interval    Specify interval for load calculation for an interface
  local-proxy-arp  Enable local proxy ARP
  logging          Per-interface logging configuration
  mac-address      Set the Mac address(xxxx.xxxx.xxxx) on an interface
  maintenance      Configure maintenance embargo flag on the given interface
  mtu              Set the MTU on an interface
  no               Negate a command or set its defaults
  proxy-arp        Enable proxy ARP
  pwd              Commands used to reach current submode
  root             Exit to the global configuration mode
  service-policy   Configure a service policy
  show             Show contents of configuration
  shutdown         shutdown the given interface
  vrf              Set VRF in which the interface operates

I thought IOS-XR would improve such simple things, especially as now it has become mature.

Wouldn't it be better to have some of the commands that are not applicable to interface configuration under a different paragraph, like below?

RP/0/RSP0/CPU0:ASR9k1(config-if)#?    
  address-family   AFI/SAFI configuration
  arp              Configure Address Resolution Protocol
  bandwidth        Set the bandwidth of an interface
  crypto           Set crypto parameters
  dampening        configure state dampening on the given interface
  description      Set description for this interface
  frame-relay      Frame Relay interface configuration commands
  ipv4             IPv4 interface subcommands
  load-interval    Specify interval for load calculation for an interface
  local-proxy-arp  Enable local proxy ARP
  logging          Per-interface logging configuration
  mac-address      Set the Mac address(xxxx.xxxx.xxxx) on an interface
  maintenance      Configure maintenance embargo flag on the given interface
  mtu              Set the MTU on an interface
  no               Negate a command or set its defaults
  proxy-arp        Enable proxy ARP
  service-policy   Configure a service policy
  shutdown         shutdown the given interface
  vrf              Set VRF in which the interface operates
  ---------------------------------------------------------
  clear            Clear the uncommitted configuration
  commit           Commit the configuration changes to running
  describe         Describe a command without taking real actions
  do               Run an exec command
  exit             Exit from this submode
  pwd              Commands used to reach current submode
  root             Exit to the global configuration mode
  show             Show contents of configuration

Just wondering....


Notes

NX-OS has already solved that problem.

How to assign IPv6 addresses to broadband CPEs

During the last months i've been experimenting a lot with all possible IPv6 address assignment methods to a broadband subscriber. As is the case with most ISPs and IPv6, we are testing every possible scenario before we put one (or a combination) of them into production; nevertheless we still haven't decided which path to follow on every aspect. And although we have made up our minds on many of those dilemmas, the one that will remain unresolved for a little bit more is the choice between dynamic vs static addresses.

Based on various RFCs, Broadband Forum's TRs, blogs (i.e. Ivan's) and IETF WG presentations, i have gathered below all possible address assignment scenarios/methods, when it comes to a broadband (PPPoE) IPv6 subscriber CPE. Single host connectivity is out of the scope of this list, because it doesn't seem applicable for wireline providers.

Some of these methods have already been verified internally (using mostly Cisco equipment, followed closely by Juniper), others are waiting to be verified and a few are under evaluation whether they actually can be implemented and verified. So, if you believe that something is not applicable, please write down your objection, so we can discuss it. Also, if you find something missing, please feel free to add it in your comment.

I have put them in 3 different areas, based on the interface and the address type. Each area includes various mechanisms related to address assignment.

• CPE WAN Interface - Link-Local IPv6 Address
• IPv6CP (RFC 5072)
• Random/Unique Interface-Id
• "Framed-Interface-Id" from Radius (RFC 3162)
• CPE WAN Interface - Global Unicast IPv6 Address/Prefix
• SLAAC (RFC 4862)
• RA using a locally configured IPv6 pool on BRAS
• RA using a "Framed-IPv6-Pool" from Radius (RFC 3162) to define a locally configured IPv6 pool
• RA using "Framed-IPv6-Prefix" from Radius (RFC 3162)
• Stateful DHCPv6 (RFC 3315)
• IA_NA using a locally configured IPv6 address prefix pool on BRAS
• IA_NA using an external DHCPv6 server, having BRAS as Relay Agent
• IA_NA using "Framed-IPv6-Pool" from Radius (RFC 3162) to define a locally configured IPv6 pool on BRAS
• IA_NA using "Framed-IPv6-Address" from Radius (draft-ietf-radext-ipv6-access)
• CPE LAN Interface - Global Unicast IPv6 Prefix
• DHCPv6-PD (RFC 3633)
• IA_PD using "Delegated-IPv6-Prefix" from Radius (RFC 4818)
• IA_PD using "Framed-IPv6-Prefix" from Radius (RFC 3162) for $username-dhcpv6 (if RFC 4818 is not supported)
• IA_PD using "Framed-IPv6-Prefix" from Radius (RFC 3162) (if global addresses are not used on the WAN interface)
• IA_PD using a locally configured IPv6 prefix pool on BRAS
• IA_PD using an external DHCPv6-PD server, having BRAS as Relay Agent
• IA_PD using "Framed-IPv6-Pool" from Radius (RFC 3162) to define a  locally configured IPv6 prefix pool on BRAS
• IA_PD using "Delegated-IPv6-Prefix-Pool" from Radius (draft-ietf-radext-ipv6-access) to define a locally configured IPv6 prefix pool on BRAS

Acronyms
RA = Router Advertisement
IA_NA = Identity Association for Non-temporary Addresses
IA_PD = Identity Association for Prefix Delegation

Color Codes
GREEN : Verified
ORANGE : To be verified
BLUE : To be implemented and verified
RED : Probably not applicable

What i see as the most interesting options are the following two:

• "Framed-IPv6-Prefix" for WAN (through SLAAC) and "Delegated-IPv6-Prefix" for LAN
• "Framed-IPv6-Address" for WAN (through DHCPv6) and "Delegated-IPv6-Prefix" for LAN

Hopefully we'll soon have support of "draft-ietf-radext-ipv6-access" by BRAS vendors and we'll be able to verify another bunch of them.


Notes 

• Radiator has been used as the radius server for all our internal tests. Its flexibility probably puts it at the top of the market.
• Technically, IPv6CP is not an address assignment method (like IPCP). It just helps/hints the peer to build a possible IPv6 link-local address by negotiating a 64bit Interface-Id option. There have been various draft RFCs (draft-huang-ipv6cp-options, draft-qin-pppext-ipv6-addr-pref) that were supposed to add more options to it (like Prefix, IPv6-Address, Delegated-Prefix, DNS-IPv6-Address, etc.), but they expired and never moved into standard status. Two new ones (draft-hu-pppext-ipv6cp-requirements, draft-hu-pppext-ipv6cp-extensions) have brought the issue into surface again. IETF members' usual answer is that PPP is a link-layer protocol, so higher level (i.e network,application) protocols should be left outside.

How to find the peer IPv6 address of a PPPoE subscriber

In the IPv4 world you could very easily do the following on a BRAS/BNG, find the subscriber's IPv4 address and ping it.

bbras#sh users | i test
  Vi4          test PPPoVPDN     00:01:42 10.11.12.13
bbras#p 10.11.12.13

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.11.12.13, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/18/24 ms

Although ping wouldn't always work, in many cases (especially under a managed CPE environment), ping was an easy way to verify subscriber's connectivity, something that is useful for the call-center or 1st level support. Besides checking basic connectivity, using just a single command (as the one shown above, or the ones shown below) you could easily (or with a little bit of text searching) find the IPv4 address of a subscriber.

bbras#sh caller user test

  User: test, line Vi4, service PPPoVPDN
        Connected for 1d05h, Idle for 00:01:54
  Timeouts:    Limit     Remaining Timer Type
               01:00:00  00:58:05  PPP idle
  PPP: LCP Open, multilink Closed, PAP (<-), IPCP, IPV6CP
  IP: Local 10.10.10.10, remote 10.11.12.13
      Access list (I/O) is 120/not set
  Counts: 27378 packets input, 534558 bytes, 0 no buffer
          0 input errors, 0 CRC, 0 frame, 0 overrun
          13703 packets output, 280432 bytes, 0 underruns
          0 output errors, 0 collisions, 0 interface resets

bbras#sh ip int virtual-access 4
Virtual-Access4 is up, line protocol is up
  Interface is unnumbered. Using address of Loopback0 (10.10.10.10)
  Broadcast address is 255.255.255.255
  Peer address is 10.11.12.13

bbras#sh ppp int virtual-Access 4
PPP Serial Context Info
-------------------
Interface        : Vi4
PPP Serial Handle: 0x0
PPP Handle       : 0x0
SSS Handle       : 0x0
AAA ID           : 0
Access IE        : 0x0
SHDB Handle      : 0x0
State            : Down
Last State       : Init
Last Event       : None

PPP Session Info
----------------
Interface        : Vi4
PPP ID           : 0xC600001D
Phase            : UP
Stage            : Local Termination
Peer Name        : test
Peer Address     : 10.11.12.13
Control Protocols: LCP[Open] PAP+ IPCP[Open]
Session ID       : 29
AAA Unique ID    : 59
SSS Manager ID   : 0x3B
SIP ID           : 0x4F00003A
PPP_IN_USE       : 0x11

Vi4 LCP: [Open]
Our Negotiated Options
Vi4 LCP:    AuthProto PAP (0x0304C023)
Vi4 LCP:    MagicNumber 0x547CCD04 (0x0506547CCD04)
Vi4 LCP:    EndpointDisc 1 bbras
Vi4 LCP:    (0x13130162627261732D6C6C752D6B6C6E)
Vi4 LCP:    (0x2D3331)
Our Rejected options
  MRRU
Peer's Negotiated Options
Vi4 LCP:    MagicNumber 0x3DB09C3A (0x05063DB09C3A)

Vi4 IPCP: [Open]
Our Negotiated Options
Vi4 IPCP:    Address 10.10.10.10 (0x0306C2DBE763)
Peer's Negotiated Options
Vi4 IPCP:    Address 10.11.12.13 (0x0306C2DB711D)
Vi4 IPCP:    PrimaryDNS 10.1.1.1 (0x8106C15C9603)
Vi4 IPCP:    SecondaryDNS 10.2.2.2 (0x8306C15C030B)

Now, in the IPv6 world, you can have quite a few of IPv6 "addresses" on the CPE (link-local address, SLAAC/DHCPv6 prefix/addresses for the WAN, DHCPv6-PD prefix/addresses for the LAN) and very limited info on the BRAS/BNG, that actually there is no easy way to do something similar.

First of all, there isn't any "show ipv6 users" command. And if there was one, which IPv6 address should it display there?

Secondly, although in 99% of the cases you can set the Framed-Interface-Id per user, this doesn't mean it will be honored. The problem with Framed-Interface-Id is that it is used as a hint to the peer, so you cannot always depend on your own being used at the end. Btw, Broadband Forum TR-187 R-32 proposes to have the BRAS/BNG decline the tentative Interface-Id received from CPE in case a Framed-Interface-Id from Radius is being used.

In any case, a manual concatenation of the prefix + Id would produce the asked IPv6 addresses.

So if you want to find the IPv6 address of a subscriber, you have to do some of the following steps:

bbras#sh ipv6 int virtual-access 4
Virtual-Access4 is up, line protocol is up
  IPv6 is enabled, link-local address is FE80::EE44:76FF:FEC8:5C1B
  No Virtual link-local address(es):
  Interface is unnumbered. Using address of Loopback0
  No global unicast address is configured

Note: peer IPv6 address is not included as probably expected in the "show ipv6 int" output. The one shown above, is the link-local IPv6 address on the BRAS/BNG side.

Adding the "prefix" keyword at the end of the previous command, reveals the Framed-IPv6-Prefix being used on this interface:

bbras#sh ipv6 int virtual-access 4 prefix
IPv6 Prefix Advertisements Virtual-Access4
Codes: A - Address, P - Prefix-Advertisement, O - Pool
       U - Per-user prefix, D - Default
       N - Not advertised, C - Calendar

PD default [LA] Valid lifetime 2592000, preferred lifetime 604800
OD 2999:2148:100:300::/64 [LA] Valid lifetime 2592000, preferred lifetime 604800

Under PPP you can find IPv6CP and the corresponding Framed-Interface-Id:

bbras#sh ppp int virtual-Access 4 | b IPV6CP:
Vi4 IPV6CP: [Open]
Our Negotiated Options
Vi4 IPV6CP:    Interface-Id EE44:76FF:FEC8:5C1B (0x010AEE4476FFFEC85C1B)
Peer's Negotiated Options
Vi4 IPV6CP:    Interface-Id 3131:3131:3A31:3131 (0x010A313131313A313131)

So, now you have the following info:

Framed-IPv6-Prefix: 2999:2148:100:300::/64
Framed-Interface-Id: 3131:3131:3A31:3131
Link Local prefix: FE80::/10

Based on these strings, you can create the following IPv6 addresses:

Peer global address: 2999:2148:100:300:3131:3131:3A31:3131
Peer link-local address: FE80::3131:3131:3A31:3131

And you can verify connectivity to them accordingly:

bbras#p 2999:2148:100:300:3131:3131:3A31:3131

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2999:2148:100:300:3131:3131:3A31:3131, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/16/16 ms

bbras#p FE80::3131:3131:3A31:3131%Virtual-Access4

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to FE80::3131:3131:3A31:3131, timeout is 2 seconds:
Packet sent with a source address of FE80::EE44:76FF:FEC8:5C1B%Virtual-Access4
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/17/20 ms

Many thanks to Ole Troan for sharing the "%interface" trick with me ("%interface" is usually used to define the zone index on UNIX systems). I hope our talk about an IPv6 output similar to "show users" will have a positive end inside IOS code.