idnits 2.17.1 draft-sumanta-ipv6-multihoming-solution-01.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: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 12 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'Fig 3' is mentioned on line 403, but not defined Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group M.G.D.Sumanta 2 Internet-Draft IMTEC 3 Intended status: Informational September 14 , 2016 4 Expires: March 14, 2017 6 IPv6 Multihoming with transparent End-to-End connectivity 7 draft-sumanta-ipv6-multihoming-solution-01 9 Abstract 11 IPv6 Multihoming design help host(s) in a site to switch dynamically 12 between multiple attached global internet without impacting 13 transport and application layer protocol whenever failure occur. 14 Basic issue on this design when ipv-to-ipv6 Network prefix 15 translations not being used are:- 16 1. Source addresses selection, 2. Next hop selection and 17 3. DNS resolution. 18 Even though Ipv6-to-Ipv6 Network prefix translation (NPTv6) solve 19 above mention problems, NPTv6 not ideal as it's not achieve 20 End-to-End transparency of connectivity .Alternatively by using 21 policy at End host to select source address and next hop also 22 solve above mention issues. 23 This document proposes solution which defines how automatically a 24 policy can be enforced on host by first hop router using router 25 advertisement. That's reduced administrative effort of updating policy 26 on all hosts in site. This document not obsolete any of the previous 27 work, only propose how policy on End-host can be enforce from router 28 by mapping destination prefix with DNS via Router Advertisement. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as work in progress." 45 This Internet-Draft will expire on March, 2017. 47 Copyright Notice 49 Copyright (c) 2015 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.1. Reserved Words . . . . . . . . . . . . . . . . . . . . . 4 66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 3. Problem Statement ............... . . . . . . . . . . . . . . 5 68 3.1. Wrong Source address selection. ......................... 5 69 3.2. Wrong Next hop selection. . . . . . . . . . . . ...... . 5 70 3.3. Private and Public RDNSS co-existence. . . . . . . . . .. 5 71 4. Router Advertisement message on details . . . . . . . . . .. 5 72 4.1. Router Advertising message. . . . . . . . . . . . . . . . 5 73 4.2. Recursive DNS Server option.. . . . . . . . . . . . . . . 6 74 4.3 DNS Search list option. ................................ 6 75 4.4 Router information option. .............................. 6 76 5. Solution . . . . . . . . . . . . . . . . . . . . . . ........ 7 77 5.1. Next Hop selection . . . . . . . . . . . . . . . ..... 7 78 5.2. Source Address Selection . . . . . . . . . . . . . . . . 8 79 5.3. Private and Public RDNS co-existence . . . . . . . . . .. 9 80 5.4. DNS search-list extension ............................. 9 81 6. Security Considerations . . . . . . . . . . . . . . . . . . .. 9 82 7. IANA Considerations ......................................... 10 83 8. Acknowledgements ............................................ 10 84 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 85 9.1. Normative References . . . . . . . . . . . . . . . . . .. 10 86 9.2. Informative References . . . . . . . . . . . . . . . . .. 10 87 Author's Address . . . . . . . . . . . . . . . . . . . . . . .. 11 89 1. Introduction 91 Multi Homing has been architect to exchange IP packet uninterruptedly 92 from local host to remote host or vice versa even when underlying 93 connectivity change dynamically. It is being designed to support 94 changing path without knocking session of the application. 96 +------+ 97 |remote| 98 | host | 99 | R | 100 +------+ 101 | 102 + - - - - - - - - - - - + 103 | Internet Connectivity | 104 + - - - - - - - - - - - + 105 / \ 106 +---------+ +---------+ 107 | ISP A | | ISP B | 108 +---------+ +---------+ 109 | Path A | Path B 110 + - - - - - - - - - - - - - - - - - - - - + 111 | multi- | | | 112 homed +------+ +------+ 113 | site | site-| | site-| | 114 | exit | | exit | 115 | |router| |router| | 116 | A | | B | 117 | +------+ +------+ | 118 | | 119 | local site connectivity | 120 | 121 | +-----------+ | 122 |multi-homed| 123 | | host | | 124 +-----------+ 125 + - - - - - - - - - - - - - - - - - - - - + 127 Fig 1 : Complete figure of ipv6 multiHoming. 129 Network Address and port Translation (NAPT) one of the solution which 130 being used in Ipv4 Multihoming scenario also can be used in Ipv6. 131 Ipv6-to-Ipv6 network prefix translation (NPTV6) RFC 6296 [RFC6296] work 132 on basic principle, End host address being mapped with a global address 133 and confined End host address visibility from outside network. Invisible 134 nature of Network address translation prevent End-to-end transparency. 135 Unlike Ipv6, in Ipv4 where global address are scarce resource, 136 Network Address Translation could be ideal solution. 137 That unlikely the case in IPv6, which have enough address to uniquely 138 address every conceivable host on internet without using network address 139 Port Translation (NAPT) [ RFC3022] 141 Adequate number of Ipv6 global unique address and support for multiple 142 addresses in node make easy to implement end host with multiple unique 143 address from different service provider its being connected. This 144 ensure end-to-end transparent connection. However there are 145 several issue in this kind of implementation or design, 146 Issues can be broadly categories in to : 147 A. Wrong Source address selection. 148 B. Wrong Next hop selection. 149 C. Private and public RDNSS co-existence. 150 On way to get ride off above mention issues from multi address assigned 151 end host implementation would be using policy on end host to select 152 Source address and Next hop. 153 On complex uses case, end host policy definition will be so complex that 154 it's difficult to achieve complete error free. Complexity arise 155 due to multiple next hop, source address and DNS presence and any wrong 156 combination will raise reachability issue or ingress filtering on 157 service provider ingress end. It get further complicated on deployment 158 where local destination reachable via a particular site and remote 159 destination reachable via multiple sites. Further, manual policy 160 configuration on end host subjected to changeable whenever service 161 provider's or local site's DNS, default gate way router and numerous 162 destination changes. 164 RFC 7157 [RFC 7157] also talk about same issue described here. 165 RFC 7157 described how police implementation in end host solve issue. 166 This document further narrate how the policy can be created 167 automatically by router using router advertisement. This document 168 also describe how public private name space information being feed to 169 host , so that host can select right next hop and source address to 170 resolve domain name on mix environment of public and private RDNSS. 172 RFC 6724 [RFC6724] laid down guideline for Address selection rule.That's 173 work fine when multiple interface are from different address space like 174 unicast , multicast ,Ipv4 and IPv6 or from different scope within IPv6 175 like link-local , global etc. However, when multiple address from same 176 scope present above mention issue persist. Multihomed host which is 177 connected to multiple internet providers have multiple global scope 178 address configured from connected provider dependent address space. 179 1.1. Reserved Words 180 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 181 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 182 document are to be interpreted as described in [RFC2119]. 184 2. Terminology 185 NPTv6 IPv6-to-IPv6 Network Prefix Translation as described in 186 [RFC6296]. 187 NAPT Network Address Port Translation as described in 188 RFC 3022 [RFC3022]. In other contexts, NAPT is often pronounced 189 "NAT" or written as "NAT". 190 MHMP Multihomed with multi-prefix. A host implementation that 191 supports the mechanisms described in this document; 192 selection, and DNS selection policy. 193 namely, source address selection policy, next hop 194 3. Problem Statement 196 +------+ ___________ 197 | | / \ 198 +---| rtr1 |=====/ network \ 199 | | | \ 1 ISP A / 200 +------+ | +------+ \___________/ 201 | | | 202 |host |-----+ 203 | | | 204 +------+ | +------+ ___________ 205 | | | / \ 206 +---| rtr2 |=====/ network \ 207 | | \ 2 ISP B / 208 +------+ \___________/ 210 Fig 2: Ipv6 Multi homing Part figure. 212 3.1 Wrong Source address selection. 214 When multiple address assigned on End host,End host may 215 select different Source address the the right source address need to 216 reach via a service provider. Wrong source address selection does not 217 alarming without service provider have ingress filter applied as packet 218 with any global address perfect to travel global scope. However, 219 uncertainty on service provider ingress filter presence impose packet's 220 source address should be particular service provider dependent address. 221 Otherwise, will be filter out on service provider network by ingress 222 rule. Having different service provider dependent source address compare 223 to service provider packet being forwarded consider as wrong source 224 address selection. 226 3.2 Wrong Next hop selection. 228 End host for all off-link prefix, consider default router address as 229 next hop. Default routers are being advertise using dynamic router 230 advertisement process. Selection of default router is either by 231 round robin or by preference setting. RFC 4861 [RFC4861] and 232 RFC 4191 [RFC4191] describe in details. Further, end host could be 233 router capable and have routing table entry corresponding to different 234 destination. However, practice of having routing info limited on End 235 host, due to memory and computation requirement. Nondeterministic nature 236 of default router selection may lead to scenario where host chose a 237 next hop which does not have reachability to reach particular 238 destination. Or Host select a next hop to reach DNS for domain name 239 esolve can not forward to selected DNS. Further, Ingres filtering, state 240 full farewells and unicast revers path filtering (uRPF) RFC3704[RFC3704] 241 also disrupt traffic on wrong next hop selection. Similarly packet when 242 need o be routed through a particular local site,next hop selection play 243 a pivotal role for successful packet delivery. 245 3.3 Private and Public RDNSS co-existence. 247 In an implementation End host could only send default queries to the 248 RDNSS present in Internet and queries related to the private namespace 249 to the RDNSS of the private network. This can be configured by setting 250 the RDNSS of the private network to know about listed domains and 251 networks, but not to be a default RDNSS. Typical issue with this 252 implementation , end host does not has clue which DNS to reach for 253 which destination URL ,wrong estination choice will lead to unsuccessful 254 attempts on address resolve process .Even if selection of DNS problem 255 being bell out, further packet forwarding should be with same source 256 address and next hop. Otherwise packet will not get fate to reach 257 final destination.Such way, presence of private and public RDNSS 258 co-existence provoke more complex issue egards o sourc address and 259 next hop selection. 261 4. Router Advertisement message on details 263 4.1 Router Advertising message. 265 0 1 2 3 266 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 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | Type | Code | Checksum | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | Cur Hop Limit |M|O| Reserved | Router Lifetime | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | Reachable Time | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | Retrans Timer | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | Options... 277 +-+-+-+-+-+-+-+-+-+-+-+- 279 4.2 Recursive DNS Server option. 281 0 1 2 3 282 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 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | Type | Length | Reserved | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 | Lifetime | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | | 289 : Addresses of IPv6 Recursive DNS Servers : 290 | | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 4.3 DNS Search list option. 295 0 1 2 3 296 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 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | Type | Length | Reserved | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | Lifetime | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | | 303 : Domain Names of DNS Search List : 304 | | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 4.4 Router information option. 309 0 1 2 3 310 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 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 | Type | Length | Prefix Length |Resvd|Prf|Resvd| 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 | Route Lifetime | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 | Prefix (Variable Length) | 317 . . 318 . . 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 5. Solution 322 100::/ 323 +------+ ___________ 324 fe80::11 | | / \ DNS 101::1 325 +---| rtr1 |=====/ network \ 326 | | | \ 1 ISP A / 327 +------+ | +------+ \___________/ 328 | | | 329 |host |-----+ 330 | | | 200::/ 331 +------+ | +------+ ___________ 332 | | | / \ 333 +---| rtr2 |=====/ network \ DNS 202::1 334 fe80::12 | | \ 2 ISP B / 335 +------+ \___________/ 337 Fig 3: Ipv6 Multi homing Part figure. 339 5.1 Next Hop selection 341 Network designer or Administrator should provision router to aware 342 of DNS address and service provider prefix which end host will use as 343 DNS address to resolve destination URL and provided prefix to build up 344 its interface address respectively. Administrator should provision 345 correct mapping of this information, so that when end host select 346 service provider prefix corresponding address as source address and 347 pair DNS address , packet forward successfully. Also, particular router 348 is the prefer router to reach destination for both DNS traffic and 349 data traffic using corresponding service provider dependent source 350 address. This should be ensure for error free traveling to destination 351 with correct mapping of source address and next hop. Further Router 352 will send router advertisement with router information list carrying 353 DNS server prefix with prf value as high. By receiving such router 354 advertisement, host select advertising router link-local address as 355 next hop or default gate way router to reach prefix mention on router 356 information list. Hence, to reach particular DNS host will chose 357 advertising router as next hop. Further all traffic destined for same 358 destination should use same Next hop as its being used to reach DNS 359 while discovering domain to address mapping. In some case host may 360 know destination ipv6 address and do not go through DNS resolve process. 361 In that circumstances, if destination belongs to particular 362 service provider dependent prefix or prefix being advertise through 363 Router advertisement on its router information list setting, 364 advertising router Link-local address being used as next hop address. 365 In other all case Next hop being selected current rule 366 of random selection. 368 Example : 370 In above [Fig 3], consider ISP A DNS server address 101::1 and 371 ISP B DNS server address 202::1. When rtr1 send RA message 372 along with all info it's propagate to host, Recursive DNS option, 373 DNS search list option; it's also should add Router 374 information option , for prefix 101::1/128. By receiving such RA, 375 host will set highest default router as rtr1 link-local address 376 for 101:: 1/128 prefix. Similarly, rtr2's link-local will be 377 considered as highest default router for prefix 202:: 1/128.Now 378 there is no difficulty to select correct next hop. If host want 379 to resolve via ISP A, it will choose rtr1 and when 380 via ISP B it will choose rtr2. 382 5.2 Source Address Selection 384 Similar to Next hop rule , Network designer or 385 Administrator should provision router to aware of service provider 386 prefix and DNS address which end host will adopt to build up its 387 interface address and to use as DNS to resolve destination URL 388 respectively. Router should hold correct mapping of this information, 389 so that if end host wanted to reach any destination including mapping 390 DNS using provision prefix corresponding source address, particular 391 router should be the next hop. This should be ensure. Router send 392 router advertisement with router information list carrying DNS server 393 prefix with prf value as high. By receiving such router 394 advertisement, hos ensure while advertising router being chosen as 395 Next hop address, advertise prefix corresponding address also being 396 chosen as source address. Even for the traffic which not going 397 through DNS resolve, also should chose source address based on Next 398 hop its select. That ensure right choice of source address in all 399 implementations and use cases. 401 Example : 403 In above figure [Fig 3] rtr1 send RA with prefix 100::/64 to configure 404 ISP dependent address. Rtr1 Link-local address is fe80::11 Similarly 405 rtr2 send RA with prefix 200::/64 to configure ISP dependent address. 406 Rtr2 Link-local address is fe80::12 Let consider 400::/64 is the 407 destination traffic need to be destine. As this is being off-link 408 prefix, traffic is being send base on default router and next hop 409 will be selected as either rtr1 or rtr2 link-local address. Proposed 410 enhancement will select source as 100::xxxx address when rtr1 is 411 being selected as next hop or will select 200::xxx 412 address when rtr2 is being selected as next hop. 414 5.3 Private and Public RDNS co-existence 416 When a local site have private DNS , router should advertise 417 local DNS prefix mapping to DNS search list containing entire 418 private domain name. Also, when site local have local destination 419 without subject to DNS resolve, those local destination also should 420 be advertise on router advertisement in router information list 421 setting prf bit high. In other word, administrator should 422 ensure all destination prefixes are being advertise on router 423 information list for which particular router must be consider as 424 Next hop. As RFC 4191 [RFC4191] already laid guideline,how host 425 should behave and which default router would be selected 426 based on router information list prefix and prf bit value further 427 not being described here. Using same guideline and with care full 428 declaration of router information list would help to nail down all 429 issues related to Next Hop and Source address selection on Private 430 and Public RDNS co-existence network. 432 5.4 DNS search-list extension 434 0 1 2 3 435 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 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 | Type | Length | RDNS | Reserved | 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 | Lifetime | 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 | | 442 : Domain Names of DNS Search List : 443 | | 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 RDNS Flag - This Flag indicate - Map domain suffix received on this 447 RA to RDNS option received in same RA. 449 6. Security Considerations 451 Major part of end host police enforcement depends on Router 452 advertisement and router information list its carry. Its 453 necessary router advertisement should be from a trusted router. 454 In a LAN to verify router advertisement from trusted source 455 there are already well define solution which carve out Rouge RA 456 problem, secure neighbor discovery etc. Also, creation of router 457 list depends on router aware ness of information which could be 458 potential thread of misinform. Careful approach of configuration 459 only by authorized network user or Authorized dynamic update process 460 should be in place to adhere those information for further use. 462 7. IANA Considerations 464 This document has no action for IANA 466 8. Acknowledgements 467 This document is influence by RFC 7157 which have details 468 explanation on Ipv6 multihoming problem and why End-to-End-Ipv6 469 translation not being a expectable solution. Also, this document 470 use some of the ASCII diagram from RFC 7157 in modified form. 471 Also acknowledge Brian E Carpenter for his feedback. this version 472 of draft mainly address his comment. 474 9. Reference 476 9.1 Normative Reference 478 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 479 Requirement Levels", BCP 14, RFC 2119, March 1997. 480 [RFC 7157] O. Troan,D. Miles ,S. Matsushima , T. Okimoto , D. Wing , 481 "IPv6 Multihoming without Network Address Translation" , 482 RFC 7157 , March 2014 483 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 484 More-Specific Routes", RFC 4191, November 2005. 486 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 487 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 488 September 2007. 490 [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 491 Translation", RFC 6296, June 2011. 493 [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, 494 "Default Address Selection for Internet Protocol Version 6 495 (IPv6)", RFC 6724, September 2012. 496 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for 497 Multihomed Networks", BCP 84, RFC 3704, March 2004. 499 9.2 Informative References 501 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 502 Address Translator (Traditional NAT)", RFC 3022, January 503 2001. 505 Static Route Option for Dynamic Host Configuration 506 Protocol (DHCP) version 4", RFC 3442, December 2002. 508 10. Author's Address 510 Sumanta Das Gajendra Mahapatra 511 Dell international services India private limited 512 Chennai , INDIA 513 Email : sumanta.dgmp@gmail.com