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

[Mark ZZZ Smith]

Hi Mike,


----- Original Message -----
> From: Michael Biber <mbiber at ipv6forum.com.au>
> To: 'Mark ZZZ Smith' <markzzzsmith at yahoo.com.au>; ausnog at lists.ausnog.net
> Cc: 
> Sent: Tuesday, 6 May 2014 12:16 PM
> Subject: RE: [AusNOG] RFC7217 - "A Method for Generating Semantically Opaque	Interface Identifiers with IPv6 Stateless Address	Autoconfiguration (SLAAC)."
> 
>T hank 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.

Any insights into why?

There are two reasons I can think of:

(a) they're comfortable the stateful, database driven method of address assignment because that is all they've experienced because they've only used IPv4.

(b) they believe that it provides them with records of who is using what address when.

The first reason is somewhat fair, although they should give SLAAC a go as it means they avoid the cost of administering address pools on a DHCPv6 server, and just use it to hand out other stateless parameters such as DNS, NTP, SIP etc. options.

The latter one is a quite common reason stated, unfortunately DHCPv4 doesn't provide a complete audit trail of address use, and neither will DHCPv6. DHCPv4 doesn't record static address use, DHCPv6 doesn't record link-local address use or static IPv6 address use. All of those types of addresses can be used for application addresses (specifically including link-locals, and they're preferred over other address types), and the DHCPv4/v6 server and its operator will be oblivious to it.

Finally, neither DHCPv4 or DHCPv6 record anything at all about the person operating the device, and given how easily mobile devices can be shared or stolen, assuming a device == a person is very flawed.


Methods to be able to identify and record the user, the address(es) they use and when, such as via 802.1X/RADIUS, would be far better evidence to support reprimanding or charging someone with unauthorised network or application use, and that is I think the actual fundamental goal the 'address auditing via DHCP' people are aiming for.

If you are interested in having a more reliable record of what addresses are in use when, either 

http://ndpmon.sourceforge.net/

or 

http://www.si6networks.com/tools/ipv6mon/


are tools that I'd look at, as they primarily work by observing Neighbor Discovery messages, and they occur regardless of the address configuration method used. (I haven't got around to running either of them up, so I haven't got advice on which of the two are better.)

> 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.

A few benefits of SLAAC over DHCPv6:

- ubiquitous, unlike DHCPv6 support (DHCPv6 support is becoming much more widespread, but if you want to be sure, use SLAAC.)

- lighter weight implementation on both the host and the router, which will become more important for "Internet of Things" and similar scenarios where the devices are low powered and long battery life is desirable (in some instances, the cost of replacing the battery could be higher than the cost of replacing the device.)

- simpler to configure, as adding a prefix to a router interface, necessary just for the router to work, will also usually (always?) enable SLAAC by default.

Regards,

Mark.


> 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
>