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:

enter image description here

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?

  • By "Interface Identifier" it means the IPv6 IID in the IP address. Also, You seem to be confusing layer-2 and layer-3. "L2 packets" are not routed. Routing happens with layer-3 addresses on layer-3 packets. Layer-2 frames are bridged.
    – Ron Maupin
    Commented Mar 6, 2018 at 14:38
  • Thank you, I tried to update the question accordingly, trying to use the correct terms now.
    – Evengard
    Commented Mar 6, 2018 at 14:46
  • Also just a question for general knoweldge, not directly related to the question but just making sure I understand terms correctly - does that mean that "bridging" two interfaces in an OS is basically like "creating a software switch with theese two interfaces"?
    – Evengard
    Commented Mar 6, 2018 at 14:48
  • Bridging means that you are using a layer-2 broadcast medium, and you are switching the frames in the same layer-2 broadcast domain. PPP doesn't bridge because it only has two possible endpoints; it is not a broadcast medium.
    – Ron Maupin
    Commented Mar 6, 2018 at 14:57
  • Well that's the point - the VPN software creates for every PPP endpoint on it's side a full ethernet virtual interface which can do all that any ethernet interfaces basically can - how the PPP endpoint and this virtual adapter "speaks" one to another is what I am implementing and what lead me to this question.
    – Evengard
    Commented Mar 6, 2018 at 15:03

2 Answers 2


...upon completion of the negotiation, different interface-identifier values are to be selected for the ends of the PPP link.

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.

  • But what if I just want the Virtual Interface 1 to actually never HAVE any IPv6 address? Because it will just (nearly) blindly redirect all IPv6 traffic received through the PPP link. Why I ever NEED for it to BE different if all I want is the Virtual Interface 1 acting as the Ethernet stack for the Client 1 IPv6 stack? I mean, sure the Virtual Interface 1 and Virtual Interface 2 MUST have different Interface Identifiers, because each of them will have their own Clients with their own IPv6 addresses but why should I bother about it for a "proxy" Virtual Interface 1 and the Client 1?
    – Evengard
    Commented Mar 6, 2018 at 15:44
  • 2
    Well, the fact that you chose to have your clients communicate over PPP (as opposed to some custom protocol of your own invention) means that you have to follow the PPP rules. You want the PPP end at Client 1 to have an IPv6 address, i.e. you want the networking stack on Client 1 to see a point-to-point interface with an IPv6 address - this means that as part of the PPP session setup it must negotiate a valid Interface Identifier. Note that the PPP RFC requirement is just to negotiate a IID; its up to you to not actually do anything with the negotiated IID
    – mere3ortal
    Commented Mar 6, 2018 at 16:09
  • Thank you! Now I get it, so basically until both the server AND the client have acknoweldged two IIDs (one for each), we can not begin IPv6 data flow as per RFC? So the server should also send a Configure packet with its tentative IID even if it doesn't really needs it?
    – Evengard
    Commented Mar 6, 2018 at 16:15
  • 2
    See, I am not sure whether it is in principle possible to have the IPv6 Control Protocol reach the "Opened" state if one end refuses to support the "Interface Identifier" configuration option described in 5072. However, given that the IID is the basis for determining the link-local address, and given that a valid link-local address is a pretty basic requirement for IPv6 to work, it seems reasonable that a successful negotiation of the IIDs is mandatory for IPv6 data flow to start. In short, yes to your question.
    – mere3ortal
    Commented Mar 6, 2018 at 16:34
  • Thank you! I think I'll mark your answer as the accepted one in a day I think, waiting for possible different interpretation. Anyway it's what I "feared" - I indeed need to negotiate two IIDs before starting the data flow.
    – Evengard
    Commented Mar 6, 2018 at 16:38

Assumption 2

This assumption is already wrong:

If you have a local IPv4 network with the network addresses 192.168.123.x and you connect some computers via VPN these computers will be assigned an IPv4 address in this range and the VPN works exactly in the way you describe it.

Using IPv6 computers may have different IPv6 addresses:

  • The link-local address (like FE80::1234)
  • Optionally local addresses (like FD12:3456::1234)
  • Optionally global addresses (like 2001:DB8::1234) for the internet access

Writing a VPN software you have two possibilities:

  • Your software uses an own sub-net

    In this case the address ranges of the computers connected via VPN differs from the network's address range.

    Compared with IPv4 this would mean: The computers connected via VPN have addresses 192.168.45.x while the actual network has the address range 192.168.123.x (netmask

    ... with all the advantages and drawbacks you have in the IPv4 scenario.

    Example: A network printer would only be accessible if it knows the router between the networks 192.168.45.x and 192.168.123.x. If it is configured not knowing the router the connection will fail.

  • Your software simulates an ethernet card for every PPP client

    In this case the interface identifier of each computer must be unique (among all PPP clients AND all computers in the ethernet).

    You also have to handle some ICMPv6/IPv6 packets specially (for example the ones that replace IPv4's ARP protocol).

  • A mixture of both would also be possible:

    PPP clients use link-local addresses only valid for the PPP link but they use local and global addresses in the same sub-net as the ethernet computers.

    Implementing this would also be some challange...


I am actually opting for the second option.

As far as I know RFCs assume that the first option is used. Therefore you will not really be RFC-compliant anyway.

... if I should negotiate as per RFC a second IID in this case for EACH client ...

The only background of the sentence in the RFC is that the link-local IPv6 address of a computer is calculated from its IID. If both ends of a PPP link have the same IID both ends would have the same IP address!

However your VPN server should only have one link-local IP address. Therefore it would be best to use the IID of the real network card of the server for all the PPP links. (Note that many OSs do not use the MAC address but a random number as IID.)

If you use different IIDs the server will have multiple IPv6 addresses!

Unfortunately under some OSs PPP first "claims" some random IID. If your network card accidentally has the same IID as it is claimed by the client you have to use a different IID (and therefore a second IPv6 address - although you have to force the client to use another IID).


I was not sure if it is possible to force the other end of a PPP link to use a certain IID. I was also not sure if the PPP stack allows any link-local address to be sent or if it only allows only the two IPv6 addresses of both ends.

If one of these two conditions is not given this would be the "killer" for the "second option" when your VPN server should work with "standard" PPP clients (software not written by you).

At least under Linux both is working.

  • I am actually opting for the second option, "Your software simulates an ethernet card for every PPP client". This is exactly what I tried to describe (apparently kinda failed), and it is why I'm asking if I should negotiate as per RFC a second IID in this case for EACH client (if for each client I will need to generate two IIDs, even if one of them won't be used). I'm well aware I will need to handle NDP at least for that. I'm thinking of generating it out of the MAC address, which is already guaranteed by the software to be unique in the subnet across both virtual and bridged physical cards.
    – Evengard
    Commented Mar 7, 2018 at 11:48
  • @Evengard I edited my post Commented Mar 7, 2018 at 21:04
  • According to the same RFC, it seems to me that we CAN force the PPP client to set an IID we desire, by just NACK-ing the one requested by the client and sending along the one we need it to set up. Even more, in PPPD it seems that there is even an option for that like "accept client IIDs or only server ones", so ther should be an option for that, right? As an interesting fact - PPP client under Windows (default one) seems to start data flow after negotiating it's own IID only, not waiting for the second one related to the server.
    – Evengard
    Commented Mar 8, 2018 at 10:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.