I am trying to implement IPv6 in an existing VPN PPP software, but having hard time of understanding some of the RFC 5072 sections meaning. Namely, section 4.1.
Assumption 1: PPP interfaces do not have MAC addresses.
The VPN server software by itself is creating for each connection a virtual ethernet interface, with it's own virtual MAC addresses etc. The software also allows bridging real interfaces too. The software itself does all the L2 switching internally between both virtual and bridged real interfaces, acting as an L2 switch. Assume this structure:
Assumption 2: for any received IPv6 packet on MAC 00:00:00:00:00:01 we will forward the packet unchanged (except for stripping the Ethernet header) through the PPP Link 1 to Client 1, and vice versa all Client 1 IPv6 packets received through PPP Link 1 will be sent unchanged into the internal virtual Ethernet switch with the originating MAC of 00:00:00:00:00:01 (creating the Ethernet header ofc). We need to do because of Assumption 1, so the Virtual Interface 1 is acting instead of Client 1 for all L2 ethernet frames handling.
Now in RFC it is said:
The interface identifier MUST be unique within the PPP link; i.e., upon completion of the negotiation, different interface-identifier values are to be selected for the ends of the PPP link. The interface identifier may also be unique over a broader scope.
This is the part which seems unclear for me: "different interface-identifier values are to be selected for the ends of the PPP link".
So, should we for Client 1 select TWO Interface Identifiers here? One for the Client 1 client side, and the second for the Virtual Interface 1 server side? It seems for me that only ONE Interface Identifier should be select based on the MAC address of Virtual Interface 1, because,
The negotiated interface identifier is used by the local end of the PPP link to autoconfigure an IPv6 link-local unicast address for the PPP interface.
Because the Virtual Interface 1 is acting instead of Client 1 for all L2 handling, it seems to me logical that the Interface Identifier used to configure the Link-Local IPv6 address should be actually based on MAC address of the Virtual Interface 1, so that the generated Link Local addres would be generated in accordance with section 2.5.6 of RFC 4291
And we don't really need for anything the second Interface Identifier negotiated for the Virtual Interface 1 itself, as we are not asigning any IPv6 address to the Virtual Interface 1 itself, it just uses the one generated by the Client 1 because all IPv6 packets are to be forwarded anyway…
Another possible interpretation I am having is that both the Client 1 side and the Server side (Virtual Interface 1 side) should both select two different interface identifiers, but during the negotiation one of them will be discarded, and only one will be accepted after negotiation.
So what does that "different interface-identifier value for both ends of a PPP link" really means?
Best Answer
In other words, by the time the negotiation is done, the two ends of the link must end up with two different values for the 64-bit interface identifier. IOW, it should be impossible that the "Client 1" end of the PPP link ends up with an identifier of 0x1122334455667788 and the "Virtual Interface 1" end also ends up with 0x1122334455667788. Because if this happens, it would mean that the IPv6 link-local addresses on the "Client 1" end would be the same as the IPv6 link-local address on the "Virtual Interface 1" end - which is obviously a Bad Thing.
The RFC talks about how a "tentative interface identifier" may be generated (from local physical MAC address, machine serial number etc.). If both ends of your system e.g "Client 1" and "Virtual Interface 1" are able to do this correctly so that their "tentative interface identifiers" are guaranteed to be unique, then the negotiation will just go through fine, with each end ACKing the other's identifier. Otherwise one end (say "Client 1") can send a value of 0 to the other end ("Virtual Interface 1"), who will then bear the responsibility of assigning an identifier to the other end.