Subject: [v6ops] Is there any SLAAC equivalent for DHCPv6 Remote-Id option?

From: Naveen Kottapalli <[email-masked]>
Date: Wed, 24 Aug 2016 14:58:45 +0530

Hello,

Can anyone tell if there is any SLAAC equivalent for *DHCPv6 Remote-Id /
DHCP Option-82* option that can be used by a gateway to know the SSID,
etc.,?

Yours,
Naveen.

---

From: Erik Kline <[email-masked]>
Date: Wed, 24 Aug 2016 18:51:56 +0900

On 24 August 2016 at 18:28, Naveen Kottapalli <[email-masked]> wrote:
> Hello,
>
> Can anyone tell if there is any SLAAC equivalent for DHCPv6 Remote-Id / DHCP
> Option-82 option that can be used by a gateway to know the SSID, etc.,?

I'm guessing it's not what you want, but there is this:

    https://tools.ietf.org/html/rfc6788#section-4

---

From: Mark Smith <[email-masked]>
Date: Wed, 24 Aug 2016 19:59:44 +1000

Hi,

> Option-82 option that can be used by a gateway to know the SSID, etc.,?

No there isn't.

SLAAC is not relayed through a router/gateway is like DHCPv4 is, so
there is no point trying to add information on the way.

SLAAC doesn't actually assign addresses to hosts either - all it does
is provides the hosts on the link with information about what
prefixes/subnets are present on the link, and hosts then generate
their own addresses from within the prefix.

In other words, if you're thinking IPv6 SLAAC is equivalent to IPv4
DHCP, they aren't, they're very different.

The use of DHCPv4 to assign addresses could be described as a
centralised database dependent host address assignment
protocol/method, where hosts don't participate in the generation and
selection of the addresses they end up using. They either take what
they're given from the DHCPv4 server or don't have an address to use.

The use of SLAAC for address assignment in IPv6 could be described as
a distributed address assignment system that doesn't have a central
database. Hosts are entirely responsible for the generation and
validation of addresses that they use based on the prefix information
supplied in RAs.

Regards,
Mark.

> Yours,
> Naveen.
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Naveen Kottapalli <[email-masked]>
Date: Wed, 24 Aug 2016 15:59:24 +0530

Hello,

If the AP is relaying the RS on a GRE tunnel to the gateway, can whatever
Erik suggested be used to inject the information whatever am looking for?

Yours,
Naveen.

---

From: Mark Smith <[email-masked]>
Date: Wed, 24 Aug 2016 20:58:38 +1000

> Erik suggested be used to inject the information whatever am looking for?

Possibly (I'd forgotten about that method) if the AP supported it.

Regards,
Mark.

---

From: Erik Kline <[email-masked]>
Date: Wed, 24 Aug 2016 20:38:21 +0900

> Possibly (I'd forgotten about that method) if the AP supported it.

Yeah, definitely a question for your vendor.

> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Naveen Kottapalli <[email-masked]>
Date: Wed, 31 Aug 2016 16:29:03 +0530

Hello,

As per section 7 of RFC 6788, Line-Identification option is encoded in
below format.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                   |  Option Type  | Option Length |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | LineIDLen     |     Line ID...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 4: Line-Identification Option Layout

Does the above layout mean that option type 0x8C will start at 2nd byte?

Yours,
Naveen.

On 24 August 2016 at 17:08, Erik Kline <[email-masked]> wrote:

> >>> > Can anyone tell if there is any SLAAC equivalent for DHCPv6
> Remote-Id /
> >>> > DHCP

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 31 Aug 2016 12:46:21 +0000

Hi Naveen,

On 08/31/2016 06:59 AM, Naveen Kottapalli wrote:
> Hello,
>
> As per section 7 of RFC 6788, Line-Identification option is encoded in below
> format.
>
>     0                   1                   2                   3

The Option type 0x8c will be in the first byte (Byte 0) of the option. The 
IPv6 ND option formats are shown like this along with a alignment requirement 
to allow for proper encoding of multi-byte fields. In this particular case 
there is no alignment required.

As for your other question upthread, I do not know of any implementations in 
WiFi APs. This option was primarily for Broadband Forum networks and AFAIK 
only BNGs and Access Nodes (e.g. DSLAMs) implemented it. If you are 
interested in using this for other purposes, please read Section 2 of the 
document to check if the issues mentioned there apply to your specific 
deployment scenario.

Thanks
Suresh

---

From: Naveen Kottapalli <[email-masked]>
Date: Wed, 31 Aug 2016 18:46:10 +0530

Thanks Suresh.  Will get back after exploring more.

Yours,
Naveen.

On 31 August 2016 at 18:16, Suresh Krishnan <[email-masked]>
wrote:

> below