Host-Identifier by Option 18 (Interface-Id)

[Andreas Hanke]

Hello together,

we have a problem with the option 18 after transmitting a IPv6 Solicit
in a relay frame.

The architecture:
1 - Client which send the IPv6 Solicit
2 - DSLAM which is inserting the option 18, interface id, as relay
(the manufacturer calls "lightweight relay")
3 - Cisco router which also works as relay, the vlan will be inserted
as interface id
4 - The dhcp server

The result of a tcpdump is attached.

Therefore I have a tcp paket with this structure:

-> RELAY FORWARD MESSAGE                        -> INSERTED BY CISCO
-> Message type: Relay-forw (12)                -> INSERTED BY CISCO
-> Interface-Id: Vl2526
-----> RELAY FORWARD MESSAGE                    -> INSERTED BY DSLAM
-----> Message type: Relay-forw (12)
-----> Interface-Id: GRE11 eth 2/1/01/03        -> (THE INFORMATION NEEDED)
----------> RELAY MESSAGE
----------> Message type: Solicit (1)           -> INSERTED BY CLIENT
----------> No Interface-Id

The structure of the paket makes sense (from bottom to top):
1.) First the client create a Solicit message because he like to get a
address from the IPv6 DHCP server. Client don't know the interface-id.
2.) The DSLAM relay and insert the Interface-Id as Option 18, which makes
possible to identify the client and give him a special ip address
3.) The Cisco Router also relay the paket because the DHCP server is not in
the same network from which the client should retrieve an address.
Also the router inserted his vlan as interface-id.


My configuration:

# Our shared network
shared-network "Lo1" {

        subnet6 2001:16e0:200::/40 {
                host AHANKENB {
                        host-identifier option dhcp6.interface-id "GRE11 eth 2/1/01/03";
                        fixed-address6 2001:16e0:200::15;
                }
        }


        # This is the subnet on which the DHCP server is hearing.
        # To this address the router forward the relay pakets.
        # But no address offering out of that subnet.
        # Just that we could start the DHCP server.
        subnet6 2001:16e0:0:f::/64 {}
}


My problem: the DHCP server don't give the fixed address to the client.
If am inserting the option.interface-id (18) direct on the client
in the dhclient.conf that works, because of (after debugging dhcp
server, I know that):

1.) At startup the dhcpd server parse the whole host-identifiers into
an hash object. This works fine.
2.) If the dhcpd server receives a relay forward (as in my case) he
looks and found out..."ok, it's a relay message, there should be an
other message into...ah, there's an other relay message, and so
on...util, another message type is found"i

-> please see dhcpv6.c -> build_dhcpv6_reply -> row 5745
-> there is a switch case which go, in case of a RELAY FORWARD
into the methode dhcp_relay_forw(reply, paket)
-> in dhcp_relay_forw(reply, paket) -> dhcpv6 -> row 5457 he found
out, there is another replay forward in and go again into
build_dhcpv6_reply

3.) As explained, with this logic the server steps to all the Relay
levels down until the SOLICIT message

-> please see dhcpv6.c -> build_dhcpv6_reply -> row 5745
-> there is a switch case which go, in case of an SOLICIT into the
methode solicit -> dhcpv6.c -> row 4113
-> and the solicit methode go into the lease_to_client (row 1245) into
dhcpv6.c which forward to methode find_host_by_option in mdb.c row 626

4.) If he found the solicit message, his logic tells him: "ok, I have
to look if I have an IP address for that solicit request"

-> sources see 3.)

5.) But there is no possiblity to give the client an address because
of into the SOLICIT message (which is direct from the client) there is
no interface-id -> so there is no hit into the hash object with the
host-identifiers

--> The problem is, that the DHCP forget the interface-id which are
added by the relays! He just looks to the interface-id which is at the
level of the solicit message! But the interface-id will be inserted
by an relay agent and not by the client (see
http://www.ipamworldwide.com/dhcp-options/isc-dhcpv6-options.html).

After that long story, my questions: ;-)
-> How could I solve that problem?
-> My idea: learn the dhcp server: don't forget the options which are
found in the "upper levels" (means: relay messages)
-> What do you think?
-> Had anyone the same problem and have already a fix?
-> Are there any config cheats?

Thanks a lot...

Regards Andreas

PS: The attached file shows the problem as .pcap -> please look into
the solicit message (3th)

R-KOM Regensburger Telekommunikationsgesellschaft mbH & Co. KG,
Kommanditgesellschaft, Sitz Regensburg, Registergericht Regensburg,
HRA 5818
Persönlich haftende Gesellschafterin und Geschäftsführung:
R-KOM Regensburger Telekommunikationsverwaltungsgesellschaft mbH,
Sitz Regensburg, Registergericht Regensburg,
HRB 6764; Geschäftsführer: Dipl.-Inf. (FH) Alfred Rauscher
-------------- next part --------------
A non-text attachment was scrubbed...
Name: record.pcap
Type: application/cap
Size: 2100 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/dhcp-hackers/attachments/20121121/cf3e34da/attachment.bin>