IPv6 only deployment using iPXE Template

**Problem: I’m trying to deploy hosts in an IPv6-only environment. I’ve configured a isc dhcpd for announcing dns bootfile-url which is http://[2001:638:902:200f:139:18:16:90]/unattended/iPXE . The Apache of Foreman is answering with an 404 and “Host unknown” no matter if iPXE loader or curl from a booted environment. When i the same with a IPv4 host - all fine. **

Expected outcome:

Foreman and Proxy versions: 1.16

Foreman and Proxy plugin versions:

**Other relevant data:

/var/log/foreman/production.log:

2018-03-13 12:04:52 9bf4bf3c [app] [I] Started GET "/unattended/iPXE" for 2001:638:902:200d:ae1f:6bff:fe25:8db8 at 2018-03-13 12:04:52 +0100
2018-03-13 12:04:52 9bf4bf3c [app] [I] Processing by UnattendedController#host_template as TEXT
2018-03-13 12:04:52 9bf4bf3c [app] [I]   Parameters: {"kind"=>"iPXE"}
2018-03-13 12:04:52 9bf4bf3c [app] [I] Current user: foreman_api_admin (administrator)
2018-03-13 12:04:52 9bf4bf3c [app] [D] Setting current user thread-local variable to foreman_api_admin
2018-03-13 12:04:53 9bf4bf3c [app] [E] unattended: unable to find a host that matches the request from 2001:638:902:200d:ae1f:6bff:fe25:8db8
2018-03-13 12:04:53 9bf4bf3c [app] [I]   Rendered text template (0.0ms)
2018-03-13 12:04:53 9bf4bf3c [app] [I] Filter chain halted as :get_host_details rendered or redirected
2018-03-13 12:04:53 9bf4bf3c [app] [I] Completed 404 Not Found in 15ms (Views: 4.5ms | ActiveRecord: 1.0ms)

host configuration:

---
parameters:
  hostgroup: urzospoc
  foreman_subnets:
  - name: URZOSPOC-V814-IPv6
    network: '2001:638:902:200d::'
    mask: 'ffff:ffff:ffff:ffff::'
    gateway: ''
    dns_primary: ''
    dns_secondary: ''
    from: ''
    to: ''
    boot_mode: Static
    ipam: EUI-64
    vlanid: ''
    network_type: IPv6
    description: ''
  foreman_interfaces:
  - ip: 
    ip6: 2001:638:902:200d:ae1f:6bff:fe25:8db8
    mac: ac:1f:6b:25:8d:b8
    name: urzospoc01.dom.uni-leipzig.de
    attrs:
      mtu: 1500
      netmask6: 'ffff:ffff:ffff:ffff::'
      network6: '2001:638:902:200d::'
    virtual: false
    link: true
    identifier: eno1
    managed: false
    primary: true
    provision: true
    subnet: 
    subnet6:
      name: URZOSPOC-V814-IPv6
      network: '2001:638:902:200d::'
      mask: 'ffff:ffff:ffff:ffff::'
      gateway: ''
      dns_primary: ''
      dns_secondary: ''
      from: ''
      to: ''
      boot_mode: Static
      ipam: EUI-64
      vlanid: ''
      network_type: IPv6
      description: ''
    tag: 
    attached_to: 
    type: Interface
  - ip: 172.18.22.94
    ip6: ''
    mac: ac:1f:6b:29:37:05
    name: ''
    attrs:
      enabled: true
      ipaddress_source: DHCP Address
      ptr: urzospocmgmt01.rz.intern.uni-leipzig.de
      subnet_mask: 255.255.255.0
      gateway: 172.18.22.254
      1_ipaddress_source: DHCP Address
      1_ipaddress: 172.18.22.94
      1_ptr: urzospocmgmt01.rz.intern.uni-leipzig.de
      1_subnet_mask: 255.255.255.0
      1_macaddress: ac:1f:6b:29:37:05
      1_gateway: 172.18.22.254
    virtual: false
    link: true
    identifier: ipmi
    managed: false
    primary: false
    provision: false
    subnet: 
    subnet6: 
    tag: 
    attached_to: 
    type: BMC
    provider: IPMI
    username: ADMIN
    password: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
  domainname: dom.uni-leipzig.de
  foreman_domain_description: ''
  owner_name: Vadim Bulst
  owner_email: vadim.bulst@uni-leipzig.de
  ssh_authorized_keys: []
  foreman_users:
    admbulst:
      firstname: Vadim
      lastname: Bulst
      mail: vadim.bulst@uni-leipzig.de
      description: ''
      fullname: Vadim Bulst
      name: admbulst
      ssh_authorized_keys: []
  root_pw: "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
  foreman_config_groups: []
  puppetmaster: urzlxdeploy.rz.uni-leipzig.de
  puppet_ca: urzlxdeploy.rz.uni-leipzig.de
  foreman_env: development

  enable-puppetlabs-pc1-repo: 'true'
  keyboard: de
  ntp-server: 139.18.1.2
  time-zone: Europe/Berlin
classes:
 
environment: development

iPXE-Template:

#!gpxe

    
kernel http://suse.uni-leipzig.de/pub/centos.org/7.4.1708/os/x86_64/images/pxeboot/vmlinuz ks=http://urzlxdeploy.rz.uni-leipzig.de/unattended/provision?token=1188bb06-9709-4a46-9f23-054b8c876f6b&static=yes ip=dhcp
initrd http://suse.uni-leipzig.de/pub/centos.org/7.4.1708/os/x86_64/images/pxeboot/initrd.img

boot

**
[e.g. logs from Foreman and/or the Proxy, modified templates, commands issued, etc]

It appears the ip address is used to lookup the host, which isn’t going to work – the unattended_controller assumes IPv4 addresses. Token-based provisioning might work.

You won’t be able to manage pure IPv6 hosts though – smart-proxy dhcp interface doesn’t support anything other than IPv4. It doesn’t look like we’ll be able to support IPv6 hosts the same way we do IPv4 ones either. For more details, pls. see https://groups.google.com/forum/#!topic/foreman-dev/M2b_gXIQxAY thread.

If you are interested in pure IPv6 setups, I’d love to hear your thoughts about the ideas in the thread above.

Hi Dmitri,
thanks for your quick answer!
Indeed I’m very interested in IPv6 setups. I’ll answer in your mentioned thread. Token-based provisioning is a possibility but this token changes from build to build right ? If not - a flashdrive cold do the job.

Cheers,

Vadim

Token-based provisioning is a possibility but this token changes from build to build right ?

A token is per successful build (gets discarded after one), and is also time-limited (gets discarded after a period of time).

Upstream recently received a small patch and unattended controller now also accepts MAC address as a HTTP parameter. This way, you can search the host in the inventory by provisioning interface MAC address to get to the iPXE contents.

What would it look like? When a client is sending a dhcp-request via IPv6-enabled iPXE-Image it will also send a DUID-UUID “dhcp unique identifier” rfc6355 with consists, in my case, the mac-address. I’m not sure but I think iPXE is generally using it.


The dhcp-server will be able to identify the client by this id. Ideally Foreman will generate a unique DHCPv6 Option-59 “Boot File URL” or a generic Option-59 plus unique Option-60 “Boot File Parameters”.
I’ve tried it by hand and it worked. I was using ISC KEA v1.1 with the following configuration:

{
"Dhcp4":
{
  "interfaces-config": {
    "interfaces": [ ]
  },
  "lease-database": {
    "type": "memfile"
  },
  "expired-leases-processing": {
    "reclaim-timer-wait-time": 10,
    "flush-reclaimed-timer-wait-time": 25,
    "hold-reclaimed-time": 3600,
    "max-reclaim-leases": 100,
    "max-reclaim-time": 250,
    "unwarned-reclaim-cycles": 5
  },
  "valid-lifetime": 4000,
  "subnet4": [
  ]
},

"Dhcp6":
{
  "interfaces-config": {
    "interfaces": [ "ens160/2001:638:902:200f:139:18:16:90" ]
  },
  "option-data": [
        {
            "name": "unicast",
            "data": "2001:638:902:200f:139:18:16:90"
        } ],
  "lease-database": {
    "type": "memfile"
  },
  "expired-leases-processing": {
    "reclaim-timer-wait-time": 10,
    "flush-reclaimed-timer-wait-time": 25,
    "hold-reclaimed-time": 3600,
    "max-reclaim-leases": 100,
    "max-reclaim-time": 250,
    "unwarned-reclaim-cycles": 5
  },
  "preferred-lifetime": 3000,
  "valid-lifetime": 4000,
  "renew-timer": 1000,
  "rebind-timer": 2000,
  "subnet6": [{
    "subnet": "2001:638:902:200d::/64",
    "option-data": [{
       "name": "dns-servers",
       "data": "2001:638:902:1::10"
    }],
    "reservations":[{
        "duid": "000400000000000000000000ac1f6b258db8",
        "option-data": [
          {
            "name": "bootfile-url",
            "data": "http://[2001:638:902:2013:4f:48ff:fe87:c6fb]/urzospoc01"
          }
        ]
    }]

  }]
 },

"DhcpDdns":
{
"ip-address": "127.0.0.1",
"port": 53001,
"tsig-keys": [],
"forward-ddns" : {},
"reverse-ddns" : {}
},

"Logging":
{
"loggers": [
  {
    "name": "kea-dhcp4",
    "output_options": [
        {
          "output": "/var/log/kea-dhcp4.log"
        }
    ],
    "severity": "INFO",
    "debuglevel": 0
  },
  {
    "name": "kea-dhcp6",
    "output_options": [
        {
          "output": "/var/log/kea-dhcp6.log"
        }
    ],
    "severity": "INFO",
    "debuglevel": 0
  },
  {
    "name": "kea-dhcp-ddns",
    "output_options": [
        {
          "output": "/var/log/kea-ddns.log"
        }
    ],
    "severity": "INFO",
    "debuglevel": 0
  }
]
}

}

This setup works with SLAAC-addresses and “Other Config”-Flag

When a client is sending a dhcp-request via IPv6-enabled iPXE-Image it will also send a DUID-UUID “dhcp unique identifier” rfc6355 with consists, in my case, the mac-address.

In your case it’s type 1 id which will change on every reboot, as it contains time component.

The dhcp-server will be able to identify the client by this id.

It might be doable in dhcpd via string matching, but would require changing the config file (not leases) for every client and restarting the process. I’m sure there will be scalability issues both with config file parsing and runtime.

These and bunch of other issues is why I chose to go with dedicated dhcp server. One of the things pixiecore does behind the scenes (when in api mode) is it extracts client’s mac address out of DUID and passes it to Foreman/Smart-Proxy.

My apologies, it’s actually a type 4 DUID, which is persistent. Not sure how it’s derived though – RFC doesn’t specify this.

It looks like this client can be made to work with isc dhcpd, as it can be matched using host-identifier option dhcp6.client-id, but this won’t work for type 1 ids, which appear to be quite common?

Well I have no idea. I just got the environment in our data center. But anyway if we talk about Foreman bare metal deployments and IPv6 then we mostlikely talk about very special setups. My intension is to bring up a Openstack/Ceph-cluster with an IPv6 underlay network where all nodes are routers and talk bgp or ospf.

I don’t agree. We are trying to go IPv6 only deployment as well. And number of IPv6 only networks will only grow.

The only reason, we still install servers via CD, is the fact that foreman doesn’t support IPv6 only setup.

It personally frustrates me that IPv6 support is generally ignored by developers (not only foreman) as well as HW vendors.

A lot of IPv6 code is missing because there was nobody in our open-source community who would wrote that. Lots of things are different from IPv4, lots of things are more difficult. It’s being addressed slowly thanks to the great amount of work done by folks here. Your words might be frustrating for them actually - please be respectful.

@skrivy:

While not my main focus, I’m spending some of my time on ipv6 support in Smart-Proxy and Foreman. Please take a look at the discussion here: https://groups.google.com/forum/#!topic/foreman-dev/M2b_gXIQxAY. There’s also a deep-dive showing the approach described in the thread in action: https://www.youtube.com/watch?v=6KJne_Hyv5k.

As always, testing and/or feedback are greatly appreciated.