[AusNOG] RFC7217 - "A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)."

[Michael Biber]

Thank you Mark.
Whenever I do training, workshops or consulting discussions, I conduct a
straw poll to see if people do or intend to use SLAAC. The answer is
invariably no, with DHCPv6 dominating and static assignment taking up the
rest. This varies by role...service provider/end user/DC/content provider.
An examination of the benefits of SLAAC or the relative positioning of the
techniques would be useful. Perhaps this has already been tackled in the
RFCs. Will take a look.
Regards,
Mike Biber

-----Original Message-----
From: AusNOG [mailto:ausnog-bounces at lists.ausnog.net] On Behalf Of Mark ZZZ
Smith
Sent: Tuesday, 6 May 2014 7:32 AM
To: ausnog at lists.ausnog.net
Subject: [AusNOG] RFC7217 - "A Method for Generating Semantically Opaque
Interface Identifiers with IPv6 Stateless Address Autoconfiguration
(SLAAC)."

Hi,

A new IPv6 related RFC was recently published which people on this list
might be interested in.

"A Method for Generating Semantically Opaque Interface Identifiers with IPv6
Stateless Address Autoconfiguration (SLAAC)."
http://tools.ietf.org/html/rfc7217

While a bit of a mouthful, this RFC is an alternative to generating the
Interface Identifier (IID) part of the IPv6 address from the interface's
link-layer address.

This method of generating an IID was developed:

- the provide IIDs that are stable across interface module/line-card etc.
changes. They have the convenience of auto-generated addresses yet the
stability of static/manually configured addresses.

- alternatively, they can be stable across 'modular' interfaces e.g., the
per-prefix address will stay with the USB dongle which ever USB port it is
attached to in the same device. Attaching it to a different device would
result in different IIDs for the same prefixes.

- to provide IIDs that don't disclose any information about the underlying
interface manufacturer or the host, as MAC address based IIDs currently do
(hence the 'semantically opaque'). Some people have been concerned about
disclosing these details, and there are also concerns that MAC based IIDs
dramatically reduce the search space for a brute force address scan of an
IPv6 subnet (If you can guess the OUIs in use, you only need to search 2^24
addresses to find hosts with interfaces with that OUI, which is a much
smaller search than all 2^64 addresses in a /64 prefix).

- to provide stable IIDs per prefix, yet that are different for different
prefixes.

They work by having the node generate a new IID when it learns of a new
prefix or a set of new prefixes via an RA, which would usually mean when it
attaches to a network. It stores that IID for those prefixes such that when
it is attached to the prefix again, it uses the same IID (as long as it
passes Duplicate Address Detection). The IID is the result of a hash of a
variety of attributes such as the prefix, ifIndex, interface name.

These addresses/IIDs are not necessarily an alternative to IPv6
privacy/temporary addresses (RFC4941). Privacy/temporary addresses are used
for outgoing communications, and also change fairly periodically e.g., once
every 8 to 24 hours. Devices with privacy/temporary addresses would still
have MAC based IIDs, that could be used for unsolicited incoming
connections, and for example would need to be disclosed via DNS for server
functions, disclosing information about the server that the operator might
want to hide.

These Opaque IIDs would provide the needed both opaqueness and stability
that privacy/temporary addresses don't. They can exist in parallel with
privacy/temporary addresses, or be used instead of privacy/temporary
addresses (with of course the loss of temporariness they provide).  

Regards,
Mark.
_______________________________________________
AusNOG mailing list
AusNOG at lists.ausnog.net
http://lists.ausnog.net/mailman/listinfo/ausnog