{"id":1119,"date":"2010-06-10T03:03:48","date_gmt":"2010-06-10T11:03:48","guid":{"rendered":"\/?p=1119"},"modified":"2010-06-19T23:19:21","modified_gmt":"2010-06-20T07:19:21","slug":"it-is-all-metcalfe%e2%80%99s-fault","status":"publish","type":"post","link":"https:\/\/www.identityblog.com\/?p=1119","title":{"rendered":"It is all Metcalfe\u2019s fault"},"content":{"rendered":"

Christian Huitema<\/a>, author of IPv6: The New Internet Protocol (2nd Edition)<\/a>\u00a0and one of the leading architects of IPV6, had this to tell us:<\/p>\n

It is all Metcalfe\u2019s <\/a>fault. There is no real functional need to have the MAC addresses unique worldwide, but it certainly is very convenient. If they weren\u2019t unique, we would have to add a protocol to detect address collisions and somehow resolve them. That\u2019s hard enough for static attachments, but becomes really hairy when dealing with a high mobility environment, e.g. Wi-Fi enabled smart phones that connect to different base stations as we roam the corridors of the buildings. Making MAC addresses unique really simplified the design, but it did not actually spare the need for detecting duplicates. Simply, we treat that as an error, to be corrected by network management systems.<\/p>\n

The initial design of IPv6 called for embedding the MAC addresses in the IPv6 address. A host IPv6 address would be built as the combination of a 64 bit network prefix and a MAC address expanded to 64 bits. Our Windows Networking team saw that as a serious issue, and we proposed an alternative design in which host pick randomized \u201chost identifiers\u201d, that vary each time they connect to a new network. That\u2019s what you get by default in Vista and in Windows 7, although managers can still force the old \u201cstandard compliant\u201d behavior and request that the identifier be set to the MAC address. I believe that most other operating systems just build IPv6 address using the MAC address.<\/p>\n

The worldwide database of MAC addresses would be even more valuable if we had kept using MAC addresses in IPv6 addresses. In fact, it may be valuable enough as most smart phone stacks still do that. Web sites and other services see the incoming IPv6 address, extract the database, and, voila, precise identification of the caller identity, location, you name it. Picture Bill Joy\u2019s smirk, \u201ctold you so.\u201d<\/p>\n

Your understanding of the Wi-Fi protocol is correct. Only the payload is encrypted, not the MAC header.\u00a0 The 802.11 MAC header actually differs from the Ethernet MAC header and carries up to 4 MAC addresses: the immediate wireless sender, the intended wireless receiver, the original source and the final destination. The final destination is used for example when sending a packet from one mobile to another through a base station. Depending of scenarios, headers carry 2, 3 or 4 Mac addresses \u2013 addresses are not repeated, for example, when the original source is the same as the wireless sender, or when the intended destination is the same as the wireless destination.<\/p>\n

The MAC header itself was not protected, at least not initially. This can lead to possible spoofing of control frames, e.g. disconnection requests. 802.11 in 2009 defined 802.11w to add protection to management frames, but this is essentially an anti-spoofing standard. It may optionally encrypt some management data, but it cannot encrypt the wireless MAC addresses.<\/p>\n

These are very\u00a0important points.\u00a0\u00a0The problem of moving between multiple base stations in the same network would make MAC encryption a non-starter unless we took a heavy dependence on communication between the base stations, introducing the reliability concerns that implies.\u00a0\u00a0In other words,\u00a0the problem is not quite\u00a0as simple as Hal Berenson suggested here.<\/a>\u00a0<\/p>\n

Yet Christian has found an elegant and simple alternative.\u00a0 I really take my hat off to\u00a0him<\/em>\u00a0 for\u00a0having been visionary enough\u00a0– and sufficiently tuned into identity issues\u00a0– to generate, by default,\u00a0a different IPV6 MAC address for each network\u00a0a device\u00a0connects to.\u00a0\u00a0 I remember\u00a0Christian discussing the issues and telling me he\u00a0saw this as a possibility but had no idea until now he had succeeded in getting it\u00a0out the door and onto millions of devices.\u00a0<\/p>\n

This approach\u00a0solves the linking problem I've been describing, because the MAC address snooped\u00a0in\u00a0your home would be different from the MAC address generated should you\u00a0go to your workplace or attend a conference.\u00a0\u00a0\u00a0In essence,\u00a0Christian has made the IPV6 MAC addresses properly unidirectional, in the sense of being contextually specific identifiers, and in this sense has brought IP into conformance with the Fourth Law of Identity.<\/p>\n

Although this benefit only kicks in as the infrastructure evolves to IPV6, it establishes the fact that the end-state we will reach is one in which WiFi snooping won't provide the ability to link people across contexts as\u00a0various commercial interests are currently attempting to do.\u00a0<\/p>\n

It also, in my view, gives me confidence that regulation preventing\u00a0collection and linking of MAC addresses\u00a0would be totally consistent with the\u00a0direction technological evolution will take us in anyway.\u00a0\u00a0 This is really key, since we\u00a0never want regulation to tell technologists what to do<\/em> – only, in protecting the public, to tell us what not to do<\/em>.\u00a0<\/p>\n

There is, however, a macabre side to Christian's comment.\u00a0<\/p>\n

Implementations of IPV6 that do<\/strong> always include a persistent and unchanging MAC address in their IPV6 address<\/em> need to be fixed.\u00a0 They make the\u00a0problem of unique identification across contexts worse, not better, since the MAC address moves up the stack to the IP layer…\u00a0\u00a0 We need the people responsible for these implementations to understand the issues and provide privacy-friendly alternatives just as Christian did.\u00a0\u00a0Looks like there is more work to be done…\u00a0<\/p>\n","protected":false},"excerpt":{"rendered":"

But the problem of network addresses is “really hairy when dealing with a high mobility environment”<\/p>\n","protected":false},"author":68,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[3,47,40,11,77],"tags":[],"_links":{"self":[{"href":"https:\/\/www.identityblog.com\/index.php?rest_route=\/wp\/v2\/posts\/1119"}],"collection":[{"href":"https:\/\/www.identityblog.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.identityblog.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.identityblog.com\/index.php?rest_route=\/wp\/v2\/users\/68"}],"replies":[{"embeddable":true,"href":"https:\/\/www.identityblog.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=1119"}],"version-history":[{"count":0,"href":"https:\/\/www.identityblog.com\/index.php?rest_route=\/wp\/v2\/posts\/1119\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.identityblog.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=1119"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.identityblog.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=1119"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.identityblog.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=1119"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}