idnits 2.17.1 draft-kuarsingh-v6ops-6to4-provider-managed-tunnel-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 abstract seems to contain references ([RFC3068], [RFC3056]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 16, 2012) is 4446 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3068 (Obsoleted by RFC 7526) == Outdated reference: A later version (-15) exists of draft-weil-shared-transition-space-request-14 -- Obsolete informational reference (is this intentional?): RFC 1981 (Obsoleted by RFC 8201) -- Obsolete informational reference (is this intentional?): RFC 3484 (Obsoleted by RFC 6724) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 v6ops V. Kuarsingh, Ed. 3 Internet-Draft Rogers Communications 4 Intended status: Informational Y. Lee 5 Expires: August 19, 2012 Comcast 6 O. Vautrin 7 Juniper Networks 8 February 16, 2012 10 6to4 Provider Managed Tunnels 11 draft-kuarsingh-v6ops-6to4-provider-managed-tunnel-05 13 Abstract 15 6to4 Provider Managed Tunnels (6to4-PMT) provide a framework which 16 can help manage 6to4 [RFC3056] tunnels operating in an anycast 17 [RFC3068] configuration. The 6to4-PMT framework is intended to serve 18 as an option to operators to help improve the experience of 6to4 19 operation when conditions of the network may provide sub-optimal 20 performance or break normal 6to4 operation. 6to4-PMT provides a 21 stable provider prefix and forwarding environment by utilizing 22 existing 6to4 Relays with an added function of IPv6 Prefix 23 Translation. This operation may be particularly important in NAT444 24 infrastructures where a customer endpoint may be assigned a non- 25 RFC1918 address thus breaking the return path for anycast [RFC3068] 26 based 6to4 operation. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on August 19, 2012. 45 Copyright Notice 47 Copyright (c) 2012 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3. 6to4 Provider Managed Tunnels . . . . . . . . . . . . . . . . 5 65 3.1. 6to4 Provider Managed Tunnel Model . . . . . . . . . . . . 5 66 3.2. Traffic Flow . . . . . . . . . . . . . . . . . . . . . . . 5 67 3.3. Prefix Translation . . . . . . . . . . . . . . . . . . . . 6 68 3.4. Translation State . . . . . . . . . . . . . . . . . . . . 7 69 4. Deployment Considerations and Requirements . . . . . . . . . . 7 70 4.1. Customer Opt-out . . . . . . . . . . . . . . . . . . . . . 7 71 4.2. Shared CGN Space Considerations . . . . . . . . . . . . . 8 72 4.3. End to End Transparency . . . . . . . . . . . . . . . . . 8 73 4.4. Path MTU Discovery Considerations . . . . . . . . . . . . 9 74 4.5. Routing Requirements . . . . . . . . . . . . . . . . . . . 9 75 4.6. Relay Deployments . . . . . . . . . . . . . . . . . . . . 9 76 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 77 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 78 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 79 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 80 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 81 8.2. Informative References . . . . . . . . . . . . . . . . . . 10 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 84 1. Introduction 86 6to4 [RFC3056] tunnelling along with the anycast operation described 87 in [RFC3068] is widely deployed in modern Operating Systems and off 88 the shelf gateways sold throughout the retail and OEM channels. 89 Anycast [RFC3068] based 6to4 allows for tunnelled IPv6 connectivity 90 through IPv4 clouds without explicit configuration of a relay 91 address. Since the overall system utilizes anycast forwarding in 92 both directions, flow paths are difficult to determine, tend to 93 follow separate paths in either direction, and often change based on 94 network conditions. The return path is normally uncontrolled by the 95 local operator and can contribute to poor performance for IPv6, and 96 can also act as a breakage point. Many of the challenges with 6to4 97 are described in [RFC6343]. A specific critical use case for 98 problematic anycast 6to4 operation is related to conditions where the 99 consumer endpoints are downstream from a northbound CGN [RFC6264] 100 function when assigned non-RFC1918 IPv4 addresses, which are not 101 routed on interdomain links. 103 Operators which are actively deploying IPv6 networks and operate 104 legacy IPv4 access environments may want to utilize the existing 6to4 105 behaviour in customer site resident hardware and software as an 106 interim option to reach the IPv6 Internet in advance of being able to 107 offer full native IPv6. Operators may also need to address the 108 brokenness related to 6to4 operation originating from behind a 109 provider NAT function. 6to4-PMT offers an operator the opportunity to 110 utilize IPv6 Prefix Translation to enable deterministic traffic flow 111 and an unbroken path to and from the Internet for IPv6 based traffic 112 sourced originally from these 6to4 customer endpoints. 114 6to4-PMT translates the prefix portion of the IPv6 address from the 115 6to4 generated prefix to a provider assigned prefix which is used to 116 represent the source. This translation will then provide a stable 117 forward and return path for the 6to4 traffic by allowing the existing 118 IPv6 routing and policy environment to control the traffic. 6to4-PMT 119 is primarily intended to be used in a stateless manner to maintain 120 many of the elements inherent in normal 6to4 operation. 121 Alternatively, 6to4-PMT can be used in a stateful translation mode 122 should the operator choose this option. 124 2. Motivation 126 Many operators endeavour to deploy IPv6 as soon as possible so as to 127 ensure uninterrupted connectivity to all Internet applications and 128 content through the IPv4 to IPv6 transition process. The IPv6 129 preparations within these organizations are often faced with both 130 financial challenges and timing issues related to deploying IPv6 to 131 the network edge and related transition technologies. Many of the 132 new technologies available for IPv4 to IPv6 transition will require 133 the replacement of the customer CPE to support technologies like 6RD 134 [RFC5969], Dual-Stack Lite [RFC6333] and Native Dual Stack. 136 Operators face a number of challenges related to home equipment 137 replacement. Operator initiated replacement of this equipment will 138 take time due to the nature of mass equipment refresh programs or may 139 require the consumer to replace their own gear. Replacing consumer 140 owned and operated equipment, compounded by the fact that there is 141 also a general unawareness of what IPv6 is, also adds to the 142 challenges faced by operators. It is also important to note that 143 6to4 is found in much of the equipment found in networks today which 144 do not as of yet, or will not, support 6RD and/or Native IPv6. 146 Operators may still be motivated to provide a form of IPv6 147 connectivity to customers and would want to mitigate potential issues 148 related to IPv6-only deployments elsewhere on the Internet. 149 Operators also need to mitigate issues related to the fact that 6to4 150 operation often is on by default and may be subject to erroneous 151 behaviour. The undesired behaviour may be related to the use of non- 152 RFC1918 addresses on CPE equipment which operate behind large NATs, 153 or other conditions as described in a general advisory as laid out in 154 [RFC6343]. 156 6to4-PMT allows an operator to help mitigate such challenges by 157 leveraging the existing 6to4 deployment base, while maintaining 158 operator control of access to the IPv6 Internet. It is intended for 159 use when better options, such as 6RD or Native IPv6, are not yet 160 viable. One of key objectives of 6to4-PMT is to also help reverse 161 the negative impacts of 6to4 in CGN environments. The 6to4-PMT 162 operation can also be used immediately with the default parameters 163 which are often enough to allow it to operate in a 6to4-PMT 164 environment. Once native IPv6 is available to the endpoint, the 165 6to4-PMT operation is no longer needed and will cease to be used 166 based on correct address selection behaviours in end hosts [RFC3484]. 168 6to4-PMT thus helps operators remove the impact of 6to4 in CGN 169 environments, deals with the fact that 6to4 is often on by default, 170 allows access to IPv6-only endpoints from IPv4-only addressed 171 equipment and provides relief from many challenges related to mis- 172 configuations in other networks which control return flows via 173 foreign relays. Due to the simple nature of 6to4-PMT, it can also be 174 implemented in a cost effective and simple manner allowing operators 175 to concentrate their energy on deploying Native IPv6. 177 3. 6to4 Provider Managed Tunnels 179 3.1. 6to4 Provider Managed Tunnel Model 181 The 6to4 managed tunnel model behaves like a standard 6to4 service 182 between the customer IPv6 host or gateway and the 6ot4-PMT Relay 183 (within the provider domain). The 6to4-PMT Relay shares properties 184 with 6RD [RFC5969] by decapsulating and forwarding encapsulated IPv6 185 flows within an IPv4 packet, to the IPv6 Internet. The model 186 provides an additional function which translates the source 6to4 187 prefix to a provider assigned prefix which is not found in 6RD 188 [RFC5969] or traditional 6to4 operation. 190 The 6to4-PMT Relay is intended to provide a stateless (or stateful) 191 mapping of the 6to4 prefix to a provider supplied prefix. 193 | 6to4-PMT Operation | 195 +-----+ 6to4 Tunnel +--------+ +------+ IPv6 +----+ 196 | CPE |-------------|6to4 BR |--| PT66 |--------- |Host| 197 +-----+ IPv4 +--------+ +------+ Provider +----+ 198 Network Prefix 199 Unified or Separate 200 Functions/Platforms 202 Figure 1: 6to4-PMT Functional Model 204 This mode of operation is seen as beneficial when compared to broken 205 6to4 paths and/or environments where 6to4 operation may be functional 206 but highly degraded. 208 3.2. Traffic Flow 210 Traffic in the 6to4-PMT model is intended to be controlled by the 211 operator's IPv6 peering operations. Egress traffic is managed 212 through outgoing routing policy, and incoming traffic is influenced 213 by the operator assigned prefix advertisements using normal 214 interdormain routing functions. 216 The routing model is as predictable as native IPv6 traffic and legacy 217 IPv4 based traffic. Figure 2 provides a view of the routing topology 218 needed to support this relay environment. The diagram references 219 PrefixA as 2002::/16 and PrefixB as the example 2001:db8::/32. 221 | 6to4 IPv4 Path | Native IPv6 Path | 222 ----------- ----------- ------------- 223 / IPv4 Net \ / IPv6 Net \ / IPv6 Internet \ 224 +------+ +--------+ +-------+ +---------+ 225 | CPE | PrefixA |6to4-PMT| PrefixB |Peering| |IPv6 HOST| 226 +------+ +--------+ +-------+ +---------+ 227 \ / \ / \ / 228 ---------- ------------ -------------- 230 IPv4 6to4 IPv6 Provider IPv6 Prefix 231 Anycast Prefix Propagation 233 Figure 2: 6to4-PMT Flow Model 235 Traffic between two 6to4 enabled devices would use the IPv4 path for 236 communication according to RFC3056 unless the local host still 237 prefers traffic via a relay. 6to4-PMT is intended to be deployed in 238 conjunction with the 6to4 relay function in an attempt to help 239 simplify it's deployment. The model can also provide the ability for 240 an operator to forward both 6to4-PMT (translated) and normal 6to4 241 flows (untranslated) simultaneously based on configured policy. 243 3.3. Prefix Translation 245 IPv6 Prefix Translation is a key part of the system as a whole. The 246 6to4-PMT framework is a combination of two concepts: 6to4 [RFC3056] 247 and IPv6 Prefix Translation. IPv6 Prefix Translation has some 248 similarities to concepts discussed in [RFC6296]. 6to4-PMT would 249 provide prefix translation based on specific rules configured on the 250 translator which maps the 6to4 2002::/16 prefix to an appropriate 251 provider assigned prefix. In most cases, a ::/32 prefix would work 252 best in 6to4-PMT which matches common RIR assignment designations to 253 operators. 255 The provider can use any prefix mapping strategy they so choose, but 256 the simpler the better. Simple direct bit mapping can be used, or 257 more advanced forms of translation should the operator want to 258 achieve higher address compression. More advanced forms of 259 translation may require the use of stateful translation. 261 Figure 3 shows a 6to4 Prefix with a Subnet ID of "0000" mapped to a 262 provider assigned globally unique prefix (2001:db8::/32). With this 263 simple form of translation, there is support for only one Subnet-ID 264 per provider assigned prefix. In characterization of deployed OSs 265 and gateways, a Subnet-ID of "0000" is the most common default case 266 followed by Subnet ID "0001". Use of Subnet ID can be referenced in 267 [RFC4291]. It should be noted that in normal 6to4 operation the 268 endpoint (network) has access to 65,536 (16-bits) Subnet IDs. In the 269 PMT case as described above using the mapping in Figure 3, all but 270 the one Subnet ID used for PMT would still operate under normal 6to4 271 operation. 273 Pre-Relayed Packet [Provider Access Network Side] 275 0 16 32 48 64 80 96 112 128 Bits 276 | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | 277 2002 : 0C98 : 2C01 : 0000 : xxxx : xxxx : xxxx : xxxx 278 | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | 279 | | | | | | 280 ---- ---- | | | | 281 | | | | | | 282 | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | 283 2001 : 0db8 : 0c98 : 2c01 : xxxx : xxxx : xxxx : xxxx 284 | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | 286 Post-Relayed Packet [Internet Side] 288 Figure 3: 6to4-PMT Prefix Mapping 290 3.4. Translation State 292 It is preferred that the overall system use deterministic prefix 293 translation mappings such that stateless operation can be 294 implemented. This allows the provider to place N number of relays 295 within the network without the need to manage translation state. 296 Deterministic translation also allows a customer to use inward 297 services using the translated (provider prefix) address. 299 If stateful operation is chosen, the operator would need to validate 300 state and routing requirements particular to that type of deployment. 301 The full body of considerations for this type of deployment are not 302 within this scope of this document. 304 4. Deployment Considerations and Requirements 306 4.1. Customer Opt-out 308 A provider enabling this function should provide a method to allow 309 customers to opt-out of such a service should the customer choose to 310 maintain normal 6to4 operation irrespective of degraded performance. 311 In cases where the customer is behind a CGN device, the customer 312 would not be advised to opt-out and can also be assisted to turn off 313 6to4. 315 Since the 6to4-PMT system is targeted at customers who are relatively 316 unaware of IPv6 and IPv4, and normally run network equipment with a 317 default configuration, an opt-out strategy is recommended. This 318 method provides the 6to4-PMT operation for non-IPv6 savvy customers 319 whose equipment may turn on 6to4 automatically and allows savvy 320 customers to easily configure their way around the 6to4-PMT function. 322 Capable customers can also disable anycast based 6to4 entirely and 323 use traditional 6to4 or other tunnelling mechanisms if they are so 324 inclined. This is not considered the normal case, and most endpoints 325 with auto-6to4 operation will be subject to 6to4-PMT operation since 326 most users are unaware of it's existence. 6to4-PMT is targeted as an 327 option for stable IPv6 connectivity for average consumers. 329 4.2. Shared CGN Space Considerations 331 6to4-PMT operation can also be used to mitigate a known problem with 332 6to4 when Shared CGN Space [I-D.weil-shared-transition-space-request] 333 or Global Unicast Addresses (GUA) that are used behind a CGN and not 334 routed on the Internet. Non-RFC but un-routed address space would 335 cause many deployed OSs and network equipment to potentially auto- 336 enable 6to4 operation even without a valid return path (such as 337 behind a CGN function). The Operators' desire to use Non-RFC1918 or 338 Shared CGN Space is considered highly likely based on real world 339 deployments. 341 Such hosts, in normal cases, would send 6to4 traffic to the IPv6 342 Internet via the IPv4 anycast relay, which would in fact provide 343 broken IPv6 connectivity since the return path flow is built using an 344 IPv4 address that is not routed or assigned to the source Network. 345 The use of 6to4-PMT would help reverse these effects by translating 346 the 6to4 prefix to a provider assigned prefix, masking this automatic 347 and undesired behaviour. 349 4.3. End to End Transparency 351 6to4-PMT mode operation removes the traditional end to end 352 transparency of 6to4. Remote hosts would connect to a 6to4-PMT 353 subject host using a translated IPv6 address versus the original 6to4 354 address based on the 2002::/16 well-known prefix. This can be seen 355 as a disadvantage of the 6to4-PMT system. This lack of transparency 356 should also be contrasted with the normal operating state of 6to4 357 which provides uncontrolled and often high latency prone 358 connectivity. The lack of transparency is however a better form of 359 operation when extreme poor performance, broken IPv6 connectivity, or 360 no IPv6 connectivity is considered as the alternative. 362 4.4. Path MTU Discovery Considerations 364 The MTU will be subject to a reduced value due to standard 6to4 365 tunnelling operation. Under normal 6to4 operation, the 6to4 service 366 agent would send an ICMP Packet Too Big Message as part of Path MTU 367 Discovery as described in [RFC4443] and [RFC1981] respectively. In 368 6to4-PMT operation, the PMT Service agent should be aware of the 369 reduced 6to4 MTU and send ICMP messages using the translated address 370 accordingly. 372 It is also possible to pre-constrain the MTU at the upstream router 373 from the 6to4-PMT service agents which would then have the upstream 374 router send the appropriate ICMP Packet Too Big Messages. 376 4.5. Routing Requirements 378 The provider would need to advertise the well-known IP address range 379 used for normal anycast 6to4 [RFC3068] operation within the local 380 IPv4 routing environment. This advertisement would attract the 6to4 381 upstream traffic to a local relay. To control this environment and 382 make sure all northbound traffic lands on a provider controlled, the 383 operator may filter the anycast range from being advertised from 384 customer endpoints toward the network (upstream propagation). 386 The provider would not be able to control route advertisements inside 387 the customer domain, but that use case is in scope for this document. 388 It is likely in that case the end network/customer understands 6to4 389 and is maintaining their own relay environment and therefore would 390 not be subject to the operators 6to4 and/or PMT operation. 392 The provider would also likely want to advertise the 2002::/16 range 393 within their own network to help bridge traditional 6to4 traffic 394 within their own network (Native IPv6 to 6to4-PMT based endpoint). 395 It would also be advised that the local 6to4-PMT operator not leak 396 the well-known 6to4 anycast IPv4 prefix to neighboring Autonomous 397 Systems to prevent PMT operation for neighboring networks. Policy 398 configuration on the local 6to4-PMT relay can also be used to 399 disallow PMT operation should the local provider service downstream 400 customer networks. 402 4.6. Relay Deployments 404 The 6to4-PMT function can be deployed onto existing 6to4 relays (if 405 desired) to help minimize network complexity. 6ot4-PMT has already 406 been developed on Linux based platforms which are package add-ons to 407 the traditional 6to4 code. The only additional considerations beyond 408 normal 6to4 relay operation would include the need to route specific 409 IPv6 provider prefix ranges used for PMT operation towards peers and 410 transit providers. 412 5. IANA Considerations 414 No IANA considerations are defined at this time. 416 6. Security Considerations 418 6to4-PMT operation would be subject to the same security concerns as 419 normal 6to4 operation. 6to4-PMT is also not plainly perceptible by 420 external hosts and local entities appear as Native IPv6 hosts to the 421 external hosts. 423 7. Acknowledgements 425 Thanks to the following people for their textual contributions and/or 426 guidance on 6to4 deployment considerations: Dan Wing, Wes George, 427 Scott Beuker, JF Tremblay, John Brzozowski, Chris Metz and Chris 428 Donley 430 Additional thanks to the following for assisting with the coding and 431 testing of 6to4-PMT: Marc Blanchet, John Cianfarani, Tom Jefferd and 432 Nik Lavorato 434 8. References 436 8.1. Normative References 438 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 439 via IPv4 Clouds", RFC 3056, February 2001. 441 [RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", 442 RFC 3068, June 2001. 444 8.2. Informative References 446 [I-D.weil-shared-transition-space-request] 447 Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and 448 M. Azinger, "IANA Reserved IPv4 Prefix for Shared Address 449 Space", draft-weil-shared-transition-space-request-14 450 (work in progress), January 2012. 452 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 453 for IP version 6", RFC 1981, August 1996. 455 [RFC3484] Draves, R., "Default Address Selection for Internet 456 Protocol version 6 (IPv6)", RFC 3484, February 2003. 458 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 459 Architecture", RFC 4291, February 2006. 461 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 462 Message Protocol (ICMPv6) for the Internet Protocol 463 Version 6 (IPv6) Specification", RFC 4443, March 2006. 465 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 466 Infrastructures (6rd) -- Protocol Specification", 467 RFC 5969, August 2010. 469 [RFC6264] Jiang, S., Guo, D., and B. Carpenter, "An Incremental 470 Carrier-Grade NAT (CGN) for IPv6 Transition", RFC 6264, 471 June 2011. 473 [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 474 Translation", RFC 6296, June 2011. 476 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 477 Stack Lite Broadband Deployments Following IPv4 478 Exhaustion", RFC 6333, August 2011. 480 [RFC6343] Carpenter, B., "Advisory Guidelines for 6to4 Deployment", 481 RFC 6343, August 2011. 483 Authors' Addresses 485 Victor Kuarsingh (editor) 486 Rogers Communications 487 8200 Dixie Road 488 Brampton, Ontario L6T 0C1 489 Canada 491 Email: victor.kuarsingh@gmail.com 492 URI: http://www.rogers.com 493 Yiu L. Lee 494 Comcast 495 One Comcast Center 496 Philadelphia, PA 19103 497 U.S.A. 499 Email: yiu_lee@cable.comcast.com 500 URI: http://www.comcast.com 502 Olivier Vautrin 503 Juniper Networks 504 1194 N Mathilda Avenue 505 Sunnyvale, CA 94089 506 U.S.A. 508 Email: olivier@juniper.net 509 URI: http://www.juniper.net