idnits 2.17.1 draft-gont-6man-managing-slaac-policy-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(ii) Publication Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC4861, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4861, updated by this document, for RFC5378 checks: 2004-07-16) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 15, 2011) is 4509 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2460' is defined on line 404, but no explicit reference was found in the text == Unused Reference: 'RFC4861' is defined on line 419, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) ** Obsolete normative reference: RFC 4941 (Obsoleted by RFC 8981) ** Downref: Normative reference to an Informational RFC: RFC 6104 -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 maintenance Working Group (6man) F. Gont 3 Internet-Draft UK CPNI 4 Updates: 4861 (if approved) December 15, 2011 5 Intended status: Standards Track 6 Expires: June 17, 2012 8 Managing the Address Generation Policy for Stateless Address 9 Autoconfiguration in IPv6 10 draft-gont-6man-managing-slaac-policy-00 12 Abstract 14 This document describes an operational problem that arises due to the 15 impossibility of managing the address generation policy employed by 16 hosts participating in IPv6 Stateless Address Autoconfiguration 17 (SLAAC). Additionally, it specifies a new field in the Prefix 18 Information option of Router Advertisement messages, such that 19 routers can advertise, for each network prefix included in a Router 20 Advertisement message, the desired address generation policy to be 21 used for SLAAC. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. This document may not be modified, 27 and derivative works of it may not be created, and it may not be 28 published except as an Internet-Draft. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on June 17, 2012. 42 Copyright Notice 44 Copyright (c) 2011 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Updating the Prefix Information option . . . . . . . . . . . . 5 61 3. Router specification . . . . . . . . . . . . . . . . . . . . . 7 62 3.1. Router configuration . . . . . . . . . . . . . . . . . . . 7 63 3.2. Router operation . . . . . . . . . . . . . . . . . . . . . 7 64 4. Host specification . . . . . . . . . . . . . . . . . . . . . . 8 65 4.1. Host configuration . . . . . . . . . . . . . . . . . . . . 8 66 4.2. Host Operation . . . . . . . . . . . . . . . . . . . . . . 8 67 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 68 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 11 69 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 70 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 71 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 72 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 73 9.2. Informative References . . . . . . . . . . . . . . . . . . 14 74 Appendix A. Changes from previous versions of the document 75 (to be removed by the RFC Editor before 76 publication of this document as a RFC . . . . . . . . 16 77 A.1. Changes from 78 draft-gont-6man-managing-privacy-extensions-01 . . . . . . 16 79 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17 81 1. Introduction 83 [RFC4862] specifies the Stateless Address Autoconfiguration (SLAAC) 84 for IPv6, which typically results in hosts configuring one or more 85 addresses composed of a network prefix advertised by a local router, 86 and an Interface Identifier (IID) that typically embeds a hardware 87 address (using the Modified EUI-64 Format [RFC4291]. 89 Since the identifiers (e.g. Ethernet MAC addresses) typically used 90 for those addresses are usually globally unique, the IPv6 addresses 91 generated as specified in [RFC4291] can be leveraged to track and 92 correlate the activity of a node, thus negatively affecting the 93 privacy of users. 95 The "Privacy Extensions for Stateless Address Autoconfiguration in 96 IPv6" [RFC4941] were introduced to difficult the task of 97 eavesdroppers and other information collectors to correlate the 98 activities of a node, and basically result in random Interface 99 Identifiers that are typically more difficult to leverage than their 100 Modified EUI-64 Format counterpart. Some flavor of these "Privacy 101 Extensions" have been implemented in a variety of systems, some of 102 which (notably Microsoft Windows Vista and Microsoft Windows 7) 103 enable them by default. 105 The impossibility of managing the address generation policy employed 106 for SLAAC poses a problem when a site desires or requires a specific 107 policy for the generation of IPv6 addresses. For example, some 108 operating systems (notably FreeBSD) implement "Privacy Extensions", 109 but do not enable them by default. And since there is currently no 110 mechanism in IPv6 to convey the desired address-generation policy, 111 administrators have no option other than manual configuration to 112 enable such extensions. On the other hand, some implementations 113 (notably Windows Vista and Windows 7) that enable "Privacy 114 Extensions" by default might need to be deployed on sites that 115 require the use of stable addresses (e.g. those resulting from 116 Modified EUI-64 Format Identifiers [RFC4291]), for the ease of 117 correlating network activities or enforcing simple access controls. 118 However, since there is currently no mechanism to convey the desired 119 address-generation policy for SLAAC, an administrator would need to 120 manually-configure each of the attached nodes such that they employ 121 the desired address generation policy. 123 Depending on manual configuration for enabling a specific and 124 homogeneous address-generation policy may result in a lot of work on 125 the side of the administrator, but may also be difficult to 126 implement, particularly when considering mobile nodes such as laptops 127 and mobile phones [Broersma]. Additionally, the lack of a mechanism 128 for conveying address-generation policy information might preclude 129 the use of some technologies, such as "Privacy Extensions" [RFC4941], 130 which are desirable in most general environments (e.g., a typical 131 home network, or an Internet cafe), but are currently only enabled as 132 a result of manual configuration. 134 This document specifies a new field in the Prefix Information option 135 of Router Advertisement messages, such that routers can advertise, 136 for each network prefix to be used for SLAAC, the desired policy for 137 the generation of IPv6 addresses. The policy information is simply 138 "advisory" information, in the sense that hosts still have the final 139 word on which address generation policy they use. 141 The aforementioned policy information basically indicates whether 142 "stable" or "temporary" addresses are desired. We note that while 143 the only address generation policies that have so far been 144 standardized by the IETF are those based on e.g. IEEE identifiers 145 and "Privacy Extensions for SLAAC", other address generation policies 146 are possible. For example, [STABLE-PRIV] describes an address 147 generation policy which results in interface identifiers that are 148 stable for each prefix used for SLAAC, but that change from one 149 autoconfiguration prefix to another. 151 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 152 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 153 document are to be interpreted as described in RFC 2119 [RFC2119]. 155 2. Updating the Prefix Information option 157 The syntax of the Prefix Information option is updated as follows: 159 0 1 2 3 160 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 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | Type | Length | Prefix Length |L|A|R|AGP|Rsvd1| 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 | Valid Lifetime | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 | Preferred Lifetime | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | Reserved2 | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | | 171 + + 172 | | 173 + Prefix + 174 | | 175 + + 176 | | 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 An additional field, the two-bit "AGP" (Address Generation Policy) 180 field, is specified for the Prefix Information option. The semantics 181 of each of the possible values are: 183 00: 184 No specific advice is provided for the generation of addresses for 185 this prefix. 187 01: 188 When generating addresses for this prefix, the resulting addresses 189 SHOULD be stable (i.e., not temporary). The resulting stable 190 addresses may be based on Modified EUI-64 Format Identifiers 191 [RFC4291], the stable private identifiers proposed in 192 [STABLE-PRIV], or any other address generation policy specified in 193 the future which results in IPv6 addresses that are stable/ 194 constant for that autoconfiguration prefix/subnet. 196 10: 197 When generating addresses for this prefix, temporary addresses 198 SHOULD be employed. The resulting addresses may be based on 199 "Privacy Extensions for SLAAC" [RFC4941], or on any other policy 200 which results in temporary Interface Identifiers. Address 201 generation policies that result in stable addresses (such as those 202 specified in [RFC4941] and [STABLE-PRIV]) SHOULD NOT be used for 203 this prefix. 205 11: 206 Unused (reserved for future use). The special value "11" is 207 reserved for future extensions, and MUST NOT be set by routers 208 implementing this specification. Hosts that implement this 209 specification MUST interpret the special value "11" in the same 210 way as "00" (i.e., no specific advice is provided for address 211 generation). 213 Note: The "R" bit was specified by [RFC3775]. The Rsvd1 field 214 corresponds to the remaining reserved bits, and thus MUST be set 215 to zero by the sender of this option, and ignored by the receiver. 217 Since the "AGP" bits correspond to a previously "reserved" field, 218 implementations that predate this specification should be setting the 219 AGP field to "00" when sending the option, and ignoring the AGP bits 220 upon receipt. 222 3. Router specification 224 3.1. Router configuration 226 This section specifies a variable that routers implementing this 227 specification MUST support: 229 DesiredAddressPolicy: 230 This variable specifies the desired address generation policy for 231 IPv6 addresses resulting from SLAAC. As of this specification, 232 possible values are: "Default", "TemporaryAddresses", and 233 "StableAddresses". This variable SHOULD default to "Default". 235 3.2. Router operation 237 A router sending a Prefix Information option MUST set the AGP bits 238 according to the value of the variable DesiredAddressPolicy. The 239 following table specifies which values must be used for the AGP field 240 depending on the value of the DesiredAddressPolicy variable. 242 +----------------------+-----------+ 243 | DesiredAddressPolicy | AGP field | 244 +----------------------+-----------+ 245 | Default | 00 | 246 +----------------------+-----------+ 247 | StableAddresses | 01 | 248 +----------------------+-----------+ 249 | TemporaryAddresses | 10 | 250 +----------------------+-----------+ 252 Table 1: Correspondence between DesiredAddressPolicy and AGP bits 254 4. Host specification 256 4.1. Host configuration 258 This section specifies two new variables that hosts implementing this 259 specification MUST support: 261 AddressPolicyConfiguration: 262 This variable specifies whether the host should honor the advice 263 conveyed in the AGP field of the received Prefix Information 264 options. There are two possible values for this variable: 265 "Enabled" and "Disabled". This variable SHOULD default to 266 "Enabled". 268 DefaultAddressPolicy: 269 This variable specifies the default IPv6 address generation policy 270 that will be employed if AddressPolicyConfiguration is set to 271 "Disabled", or if "AddressPolicyConfiguration" is set to "Enabled" 272 but the AGP field of the received Prefix Information option is set 273 to "00" (i.e., no specific advice is provided for the generation 274 of addresses for this prefix). As of this specification, possible 275 values are "TemporaryAddresses" (e.g. for [RFC4941]) and 276 "StableAddresses" (for [RFC4291] or [STABLE-PRIV]). This variable 277 SHOULD default to "TemporaryAddresses". 279 A host willing to ignore the advice of the router regarding which 280 policy to use to generate IPv6 addresses MAY do so by setting 281 AddressPolicyConfiguration to "Disabled". 283 It should be noted that the aforementioned variables might have 284 different granularities. For example, a host could specify a set of 285 EnableAddressPolicy and DefaultAddressPolicy variables on a global 286 basis, on a "per network interface type" basis, on a "per wireless 287 network" basis, etc. 289 4.2. Host Operation 291 When generating addresses for the prefix contained in a "Prefix 292 Information Option", hosts implementing this specification MUST 293 proceed as follows: 295 o If AddressPolicyConfiguration is set to "Enabled", the host SHOULD 296 employ only the policy specified by the AGP field when generating 297 addresses for this prefix. If no specific advice is provided 298 (i.e., the AGP field is set to "00"), the host SHOULD employ only 299 the policy specified by the DefaultAddressPolicy variable when 300 generating addresses for this prefix. 302 o If AddressPolicyConfiguration is Disabled, the host SHOULD employ 303 only the policy specified by the DefaultAddressPolicy variable 304 when generating addresses for this prefix. 306 5. IANA Considerations 308 There are no IANA registries within this document. The RFC-Editor 309 can remove this section before publication of this document as an 310 RFC. 312 6. Privacy Considerations 314 As discussed in [RFC4941], IPv6 addresses generated using the 315 Modified EUI-64 Format Identifiers [RFC4291] allow tracking of nodes 316 across networks, since the resulting Interface-ID is a globally- 317 unique value that will remain constant across all networks that the 318 node may connect to. 320 As specified in Section 3 and Section 4 of this document, the default 321 value for the AGP bits of a Prefix Information option is "01" (no 322 specific advice is provided for the generation of addresses for this 323 prefix), and the default address generation policy 324 (DefaultAddressPolicy) for hosts is set to "TemporaryAddresses". 325 This means that, unless the router or host default settings are 326 overridden, the default settings resulting from this specification 327 will enable the use of "temporary addresses" (such as those specified 328 in [RFC4941]). 330 Nevertheless, it should be noted that the mechanism specified in this 331 document simply provides the means for a router to convey *advisory* 332 information regarding the desired policy for generating IPv6 333 addresses when SLAAC is employed: this specification allows hosts to 334 ignore the aforementioned advice when deemed appropriate (by setting 335 AddressPolicyConfiguration to "Disabled"). For example, hosts very 336 concerned with the privacy implications of using interface 337 identifiers that remain constant across networks may set 338 AddressPolicyConfiguration to "Disabled" and DefaultAddressPolicy to 339 "TemporaryAddresses" when connecting to untrusted networks, such that 340 Temporary Addresses (such as those specified in [RFC4941]) are always 341 employed (despite the advice provided by the local router). 343 Finally, we note that the value and effectiveness of some variants of 344 Temporary Addresses (such as that specified in [RFC4941]) have been 345 questioned in a number of studies [I-D.dupont-ipv6-rfc3041harmful] 346 [Escudero] [CPNI-IPv6]. However, this document does not take a 347 stance about their value and effectiveness. 349 7. Security Considerations 351 An attacker could exploit the mechanism specified in this document to 352 cause hosts in a given subnet to disable "Temporary Addresses", thus 353 usually leading to the generation of Interface Identifiers that embed 354 the underlying hardware address (e.g. using Modified EUI-64 Format 355 Identifiers), instead. Thus, in such cases, the privacy of the 356 victim hosts that would have enabled the Privacy Extensions could 357 possibly be reduced. 359 However, some considerations should be made about such possible 360 attack. Firstly, such an attack would require from an attacker the 361 same effort as any other Neighbor Discovery attack based on crafted 362 Router Advertisement messages [RFC3756] [CPNI-IPv6], most of which 363 would be far more interesting for an attacker than this possible 364 attack vector. For example, a (possibly malicious) router could 365 still cause a host to use Modified EUI-64 Format Identifiers if 366 DHCPv6 [RFC3315] is required for address configuration, and the 367 DHCPv6 server selects the IPv6 addresses to be leased to hosts based 368 on e.g. the source link-layer address of the DHCP requests. 369 Secondly, while the the only policy for generating stable IPv6 370 addresses that has so far been standardized by the IETF is that based 371 on e.g. IEEE identifiers, there are other possible policies, such as 372 that proposed in [STABLE-PRIV], that lead to stable addresses. That 373 is, use of "stable" identifiers does not necessarily imply that such 374 identifiers remain stable/constant across networks. 376 In those cases in which the network itself is trusted, but users 377 connected to the same network are not, the possible options for 378 mitigating this and other attack vectors based on crafted Router 379 Advertisement messages include the deployment of the so-called 380 "Router Advertisement guard" mechanism [RFC6104], with the 381 implementation guidelines described in 382 [I-D.gont-v6ops-ra-guard-evasion]. Additionally, SEND (SEcure 383 Neighbor Discovery) [RFC3971] could be potentially deployed to 384 mitigate these and other Neighbor Discovery attacks. However, a 385 number of issues (such as the requirement for Public Key 386 Infrastructure) difficult the deployment of SEND in most general 387 network scenarios [CPNI-IPv6]. 389 8. Acknowledgements 391 The author would like to thank (in alphabetical order) Mikael 392 Abrahamsson, Ran Atkinson, Brian Carpenter, Christian Huitema, Mark 393 Smith, Mark Townsley, and James Woodyatt, for providing valuable 394 comments on [I-D.gont-6man-managing-privacy-extensions], on which 395 this document is based. 397 Fernando Gont would like to thank CPNI (http://www.cpni.gov.uk) for 398 their continued support. 400 9. References 402 9.1. Normative References 404 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 405 (IPv6) Specification", RFC 2460, December 1998. 407 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 408 Requirement Levels", BCP 14, RFC 2119, March 1997. 410 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 411 in IPv6", RFC 3775, June 2004. 413 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 414 Neighbor Discovery (SEND)", RFC 3971, March 2005. 416 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 417 Architecture", RFC 4291, February 2006. 419 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 420 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 421 September 2007. 423 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 424 Address Autoconfiguration", RFC 4862, September 2007. 426 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 427 Extensions for Stateless Address Autoconfiguration in 428 IPv6", RFC 4941, September 2007. 430 [RFC6104] Chown, T. and S. Venaas, "Rogue IPv6 Router Advertisement 431 Problem Statement", RFC 6104, February 2011. 433 9.2. Informative References 435 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 436 and M. Carney, "Dynamic Host Configuration Protocol for 437 IPv6 (DHCPv6)", RFC 3315, July 2003. 439 [RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor 440 Discovery (ND) Trust Models and Threats", RFC 3756, 441 May 2004. 443 [I-D.gont-v6ops-ra-guard-evasion] 444 Gont, F. and U. CPNI, "IPv6 Router Advertisement Guard 445 (RA-Guard) Evasion", draft-gont-v6ops-ra-guard-evasion-01 446 (work in progress), June 2011. 448 [I-D.gont-6man-managing-privacy-extensions] 449 Gont, F. and R. Broersma, "Managing the Use of Privacy 450 Extensions for Stateless Address Autoconfiguration in 451 IPv6", draft-gont-6man-managing-privacy-extensions-01 452 (work in progress), March 2011. 454 [I-D.dupont-ipv6-rfc3041harmful] 455 Dupont, F. and P. Savola, "RFC 3041 Considered Harmful", 456 draft-dupont-ipv6-rfc3041harmful-05 (work in progress), 457 June 2004. 459 [STABLE-PRIV] 460 Gont, F., "A method for Generating Stable Privacy-Enhanced 461 Addresses with IPv6 Stateless Address Autoconfiguration 462 (SLAAC)", Work in Progress, December 2011, . 466 [Broersma] 467 Broersma, R., "IPv6 Everywhere: Living with a Fully IPv6- 468 enabled environment", Australian IPv6 Summit 2010, 469 Melbourne, VIC Australia, October 2010, 470 . 472 [Escudero] 473 Escudero, A., "PRIVACY EXTENSIONS FOR STATELESS ADDRESS 474 AUTOCONFIGURATION IN IPV6 - "REQUIREMENTS FOR 475 UNOBSERVABILITY", RVK02, Stockholm, 2002, 476 . 478 [CPNI-IPv6] 479 Gont, F., "Security Assessment of the Internet Protocol 480 version 6 (IPv6)", UK Centre for the Protection of 481 National Infrastructure, (available on request). 483 Appendix A. Changes from previous versions of the document (to be 484 removed by the RFC Editor before publication of this 485 document as a RFC 487 A.1. Changes from draft-gont-6man-managing-privacy-extensions-01 489 o The address-generation policy information has been changed from 490 "'Modified EUI-64' vs. 'Privacy Addresses'" to "'stable addresses' 491 vs. 'temporary addresses'", thus noting that more than one 492 possible policy exists for each category. 494 o The appendix on possible alternative specifications for the AGP 495 bits has been removed. 497 o The document now focuses on a mechanism that would enable 498 increased use of "temporary addresses" (such as "Privacy 499 Extensions"). 501 Author's Address 503 Fernando Gont 504 UK CPNI 506 Email: fgont@si6networks.com 507 URI: http://www.cpni.gov.uk