unnumbered interface bahaviour

[daniel ng]

in IOS XE, when you configure an unnumbered interface to borrow address from another interface other than loopback, it will not show up in RIB thus is not able to return the traffic. a static route needs to be configured to point to the unnumbered interface as egress.

however, in IOS XR, no static route is needed despite the unnumbered interface does not show up in RIB and FIB.

in Junos, it also does not show up in RIB but does in FIB.

what is the difference between them that causes such behaviour?

[Harold Ritter]

Hi @Cristian Matei ,

No need to go in the specifics of RFC6724. This would only create more confusion.

I think I have already made it clear how "ipv6 unnumbered" overrides the SAS in the following way:

If the "ipv6 unnumbered" is configured, the SAS prefers the ipv6 address of the interface specified on that command (If considered valid by the SAS process).

If the "ipv6 unnumbered" is not configured, the SAS considers the ipv6 addresses from all the interfaces on the local node and picks the one it considers to be the best (refer to RFC6724 for the details of the selection process)  

example without ipv6 unnumbered:

int lo0

ipv6 address 2001:db8:12ff::2/128

int gi1

ipv6 address 2001:db8:12ff:12::2/64

it gi2

ipv6 address fe80::2 link-local

Traffic to 2001:db8:12ff::3 going through interface gi2 will use source address 2001:db8:12ff::2 

example with ipv6 unnumbered:

int lo0

ipv6 address 2001:db8:12ff::2/128

int gi1

ipv6 address 2001:db8:12ff:12::2/64

int gi2

ipv6 address fe80::2 link-local

ipv6 unnumbered gi1

Traffic to 2001:db8:12ff::3 going through interface gi2 will use source address 2001:db8:12ff:12::2

This is just a simple demonstration of how the "ipv6 unnumbered" overrides the SAS process.

[Cristian Matei]

Hi,

@Harold Ritter Appreciate the details, it is clear now. The IPv6 unnumbered (which, my wrong opinion, I don't see why you would ever use that, but moving on), overrides / influences the SAS process as outlined in RFC6724. At the same time, there's no mention of IPv6 unnumbered in RFC6724, which is where my confusion was.

Thanks,

Cristian.

[Harold Ritter]

Hi @Cristian Matei ,

> I don't see why you would ever use that, but moving on), overrides / influences the SAS process as outlined in RFC6724. 

I agree that this command is not as useful for ipv6 as it it for ipv4.

> At the same time, there's no mention of IPv6 unnumbered in RFC6724, which is where my confusion was.

I understand the confusion. It is not something RFC6724 mentions, but more of a implementation knob to influence the SAS outcome.

[Harold Ritter]

Hi @daniel ng ,

Let me start by saying that the meaning of "unnumbered interfaces" can be a little bit different in the ipv6 context. With IPv6, It is common to deploy core networks without configuring GUA or ULA on the interfaces connecting the different nodes. These interfaces are sometimes referred to as unnumbered interfaces, although they are not really as they at least need a link local address (LLA) to be functioning as ipv6 interfaces.

> in my test, there was only the one address in the unnumbered interface.

Bear in mind that the source address selection (SAS) works at the node level, not at the interface level. In your scenario, you have at least the ipv6 LLA on the interface where you configured the "ipv6 unnumbered" command and the non LLA address (either GUA or ULA) on the other interface.

If you ping a GUA address sitting on the other side of the unnumbered interface from the local node, the SAS behave in one of the following ways.

If the "ipv6 unnumbered" is configured, the SAS prefers the ipv6 address of the interface specified on that command.

If the "ipv6 unnumbered" is not configured, the SAS considers the ipv6 addresses from all the interfaces on the local node and picks the one it considers to be the best (refer to RFC6724 for the details of the selection process)  

 > so in other words, it is normal behaviour that no address is borrowed?

I am not to clear on what you mean by borrowed other than the concept of the ipv6 address of another interface being used as the source address for packets originated by the local node and going through the unnumbered interface.

> ps: retested on Junos version 21.4 or later where it can borrow GUA while generates its own LLA.

The JunOS implementation can be different or it might be another feature. Can you please refer to the link of the feature you are using on JunOS. 

One last point, can you please explain in more details what it is that you are trying to achieve. It will definitely help the community to suggest an appropriate solution.

[daniel ng]

very information illustration from Harold.

so 'ipv6 unnumbered' serves merely as SAS override rather than address borrowing.

although i'm not too sure what use cases this override serves other than things like fixing the source address for netflow etc.

the only official document i could find from Juniper on unnumbered interface is:
https://www.juniper.net/documentation/us/en/software/junos/interfaces-fundamentals/topics/topic-map/protocol-family-interface-address-properties.html#id-configuring-an-unnumbered-interface

from what it says and what i found, unnumbered seems to work the same for IPv4 and 6.

what i was trying to do was to make use of part of the lender interface's segment without modifying the config wherefrom.

that works fine on IPv4 with the help of static route pointing to the unnumbered interface as egress. then i found IPv6 to be the special kid in the class.

it could be achieved by bridging but that would require modifying the lender interface.

[Harold Ritter]

Hi @daniel ng ,

> so 'ipv6 unnumbered' serves merely as SAS override rather than address borrowing.

Correct.

> although i'm not too sure what use cases this override serves other than things like fixing the source address for netflow etc.

Well, I am not too sure what would be a good use case for this, but I am sure someone will. The regular SAS process is generally sufficient 

> that works fine on IPv4 with the help of static route pointing to the unnumbered interface as egress. then i found IPv6 to be the special kid in the class.

Can you please explain the details of the ipv4 solution, so we might see if it is possible with ipv6 as well.

[daniel ng]

i needed to use several new addresses in an existing segment that was currently configured in a router's interface, however i didn't have logical or physical access to the switch that connects to this interface, or any other devices in the environment.

since provisioning a new segment needs to go through bureaucratic change management and the people who manage this environment have a fetish on static routes, i came up with the idea to make use of the unnumbered interface so as not having to modify the aforementioned interface which carries live traffic.

it simply works by using 'ip unnumbered' to borrow the IPv4 address from the lender interface plus configuring corresponding static routes pointing to the unnumbered interface as egress with the new addresses as destination. with the destination prefix longer than the lender interface, the traffic will be directed to the unnumbered interface accordingly.

the static route is only needed in IOS XE since unnumbered interface does not appear in RIB as discussed earlier. IOS XR and Junos both don't need it despite its absence in RIB and/or FIB.

this is relatively a niche use case stemmed entirely from environmental constraints.

[Harold Ritter · Accepted solution]

Hi @daniel ng ,

Thanks for the detailed information. It is a pretty unusual, but clever way to use the unnumbered interface.

I ran a quick test with IOS-XE and it appears that the interface configured for "ipv6 unnumbered" does not respond to the neighbor sollicitation (NS) coming from the device connected to that same interface. I got it to work by adding a static neighbor entry (see example below) on the host and it works like a charm. 

You can always talk to your Cisco account team to request the behavior to be changed to match the one you see with ipv4, but I doubt that they would implement it given the corner case nature of your use case. Consider the following to be a workaround and not a permanent solution

Static ipv6 neighbor configuration on the host connected to the unnumbered interface:

ipv6 neighbor <unnumbered interface address> GigabitEthernet1 xxxx.xxxx.xxxx

Note that I used another IOS-XE device as the host for testing purposes.