idnits 2.17.1 draft-shyam-site-multi-41.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 document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 1022: '...ield. The value MUST be initialized t...' RFC 2119 keyword, line 1023: '... the sender, and MUST be ignored by th...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 444 has weird spacing: '... u_char icmp...' == Line 445 has weird spacing: '... u_char icmp...' == Line 446 has weird spacing: '...u_short icmp_...' -- The document date (April 26, 2017) is 2557 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5246 (ref. '5') (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 2460 (ref. '9') (Obsoleted by RFC 8200) Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT S. Bandyopadhyay 3 draft-shyam-site-multi-41.txt April 26, 2017 4 Intended status: Experimental 5 Expires: October 26, 2017 7 Solution for Site Multihoming in a Real IP Environment 8 draft-shyam-site-multi-41.txt 10 Abstract 12 This document provides a solution for Site Multihoming of stub 13 networks in a real IP environment. Each user interface in a customer 14 network may have as many global unicast addresses as many service 15 providers it will be connected with. Users can establish multiple 16 connections through different service providers simultaneously. 17 Customer networks can maintain private address space to communicate 18 within its users. Customer networks can provide IP mobility services 19 as well. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on October 26, 2017. 38 Copyright Notice 40 Copyright (c) 2017 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. 50 Table of Contents 51 1. Introduction.....................................................2 52 2. Solution for site multihoming....................................3 53 2.1. Multihoming and IP Mobility....................................5 54 2.2. Selection of source and destination address ...................6 55 2.2.1. Path selection...............................................7 56 2.2.2. Link failure and switch over to an alternate route...........8 57 2.3. Implementation aspects........................................13 58 2.3.1. Processing of system call 'getcommaddr'.....................14 59 2.3.2. Processing of 'gethostbynamewithsrcaddr'....................16 60 2.3.3. Changes required in ip_output and ip_forwarding modules.....18 61 2.3.4. Processing of protocol input routines and socket IO 62 system calls................................................18 63 2.4. Multihoming and VPN...........................................19 64 2.5. IP Address Stacking...........................................19 65 3. Security Consideration..........................................23 66 4. IANA Consideration..............................................23 67 5. Normative References............................................23 68 6. Informative References..........................................24 69 7. Author's Address................................................24 71 1. Introduction 73 Based on the definition of "multihoming" as stated in RFC3582[1], 75 "A "multihomed" site is one with more than one transit provider. 76 "Site-multihoming" is the practice of arranging a site to be 77 multihomed." 79 This is a general solution for site multihoming of stub networks in a 80 real IP world irrespective of the framework supported by the service 81 provider network. The solution is applicable to any customer network 82 that receives globally unique IP addresses for all of its nodes and 83 communicates with the rest of the world without the help of NAT[15]. 84 It is applicable to any version of IP, i.e. IPv4, IPv6 or any new 85 generation of IP that may emerge by removing the drawbacks associated 86 with IPv6[7]. Within a provider assigned address space, each customer 87 network will possess as many global unicast address space as many 88 service providers it gets connected with. So, an user interface of a 89 host may have as many global unicast addresses as many service 90 providers it will be connected with. 92 Users can maintain multiple connections through multiple service 93 providers simultaneously. A customer network can maintain private IP 94 addresses to communicate within its users. Communication using 95 private IP is restricted to private IP space for the sake of privacy. 96 Customer networks can provide IP mobility support as well. 98 There are many variants of UNIX systems (as well as real time 99 operating systems) which make use of BSD source code for their 100 implementation of TCP/IP stack. The solution given below highlights 101 the changes required with the BSD release 4.4 source code with the 102 notations used by IPv4. It addresses issues relevant to IPv6 wherever 103 applicable. All other implementations of TCP/IP have to be updated 104 in the similar manner. 106 In this document the term "default router" will refer to the customer 107 edge (CE) router that communicates with the provider network. Also 108 the term "intermediate routers" will refer to all the routers apart 109 from the CE routers. 111 2. Solution for site multihoming 113 RFC1122[2] made an extensive study related to different aspects of 114 multihoming. Some of the requirements suggested in that document 115 related to UDP and the application layer were avoided for multihomed 116 hosts in a connected network with a single gateway to reach the 117 outside world. This was achieved by the implementation of TCP/IP by 118 making sure that the interface address of an outgoing packet gets 119 selected based on the route to be followed by the destination 120 address. This criterion holds good in a connected environment with a 121 single gateway to reach the outside world. Once more than one gateway 122 comes into play to reach the outside world, either routing table of 123 the entire world has to be brought in or needs some enhancements 124 within the existing system to make the things work. 126 Whenever a customer network gets service from more than one service 127 provider, the customer network can be viewed as having multiple 128 source-id (user-id) space. Each of these IP domain gets connected to 129 different service providers through different routers. So each 130 interface of customer network may have as many global unicast 131 addresses as many service providers it is connected with. Number of 132 routing entries in the routing table will (roughly) become a multiple 133 of IP domains that it supports. Communication between any two hosts 134 within the customer network will follow the traditional routing 135 mechanism. In order to provide multihoming services it is needed that 136 a host computer always forwards packets to the customer edge router 137 associated to the same IP domain while communicating to someone in 138 the outside world. i.e. if the interface of a host computer H 139 receives an IP address 'addr1' and 'addr2' from two service providers 140 P1 and P2 which are connected through routers R1 and R2 respectively, 141 host H has to forward a packet to R1 while using its IP address as 142 'addr1' in order to send packets to the outside world. So, host 143 computers as well as the intermediate routers have to use default 144 routing based on the source domain of the source address in the IP 145 header. 147 In order to achieve this, host computers as well as intermediate 148 routers need to have information related to its IP domain (net 149 address/net mask) and the associated default router for all of its IP 150 domains. They need to have a route entry per IP domain for all of its 151 default routers. These information should be uploaded at the system 152 start up time. 154 Routing of IP packets (in the ip_output module of the hosts and in 155 the ip_forwarding module of the intermediate routers) need to be 156 modified in the following manner. 158 If destination address of a packet falls outside of its IP domains, 159 it has to be forwarded to the default router based on the domain that 160 the source address belongs to. 162 If destination address of the IP header falls within any one of its 163 IP domains, usual routing mechanism has to be followed. 165 If customer network maintains private IP domain, communication using 166 private IP has to be restricted within private IP space. 168 UDP (or RAW) based servers that need to support multiple clients 169 simultaneously need to respond to a client's request with the same 170 source address that the client had specified as the destination 171 address. In order to satisfy this, system needs to introduce two 172 system calls along with the existing system calls (i.e. read, write, 173 send, sendto, recv, recvfrom) 175 ssize_t recvwithdstaddr (int sockfd, char *buf, size_t nbytes, 176 int flags, struct sockaddr *from, socklen_t *fromlen, 177 struct sockaddr *fromcladdr, socklen_t *fromcladdrlen, 178 struct sockaddr *dst, socklen_t *dstlen, 179 struct sockaddr *dstcladdr, socklen_t *dstcladdrlen); 181 'recvwithdstaddr' receives data with destination address as specified 182 by the sender. It is similar to 'recvfrom' with the additional field 183 'dst' related to the address of the receiving interface of the host. 184 'fromcladdr' and 'dstcladdr' will hold the values of co-located care- 185 of addresses (see section 2.2) of source and destination if they 186 happen to be mobile. 188 ssize_t sendwithsrcaddr (int sockfd, char *buf, size_t nbytes, 189 int flags, struct sockaddr *to, socklen_t tolen, 190 struct sockaddr *dstcladdr, socklen_t dstcladdrlen, 191 struct sockaddr *src, socklen_t srclen, 192 struct sockaddr *srccladdr, socklen_t srccladdrlen); 194 'sendwithsrcaddr' sends data specifying the source address of the 195 outgoing interface of the host. It is similar to 'sendto' with 196 additional parameters related to source address. It behaves like 197 'sendto' if no address is specified for 'src'. 'srccladdr' and 198 'dstcladdr' will hold the values of co-located care-of addresses of 199 source and destination. 201 All the UDP based servers that need to support multiple clients 202 simultaneously, need to replace 'sendto' with 'sendwithsrcaddr' and 203 'recvfrom' with 'recvwithdstaddr'. 205 It has been expressed in several documents including RFC4291[3], that 206 a single interface will possess multiple IP addresses in a real IP 207 environment. In these cases, all the UDP servers have to be updated 208 with the system calls 'sendwithsrcaddr' and 'recvwithdstaddr' even if 209 a customer site gets attached to a single gateway to reach the 210 outside world. 212 The same logic will apply to server applications with RAW sockets. 213 Server applications that are TCP based should work in the usual 214 manner. 216 2.1. Multihoming and IP Mobility 218 For a mobile node, its co-located care-of IP address[4] has to be 219 bound to one of the IP addresses supported by the service providers 220 (if mobile node advertises more than one address, the home agent will 221 get confused, also there are other implications). Transport layer 222 must ensure that the 'home address' gets tightly coupled with that 223 particular IP address. 225 A mobile node in a foreign site will have all the IP addresses 226 supported by the foreign site as well as its "Home Address". As the 227 mobile node will also communicate with the outside world with its 228 "Home Address", user should get a provision to choose its "Home 229 Address" while initiating communication. If mobile node makes use of 230 the address of foreign site for applications that do not need its 231 "Home Address" (say, accessing a web site) cost of communication will 232 get reduced. This feature is useful when a mobile user is in a 233 foreign site but remains within the same sphere of influence (say an 234 user lives in one city but works in a different city which is in a 235 different sphere of influence and likes to access web during his 236 working hours). 238 If "Home Address" is selected for communication, the transport layer 239 of the mobile node should use its care-of address as the source 240 address and pass its "Home Address" as an option field in the stack. 241 This is because multihoming expects the source address as the 242 deciding factor for packet forwarding. 244 All the issues that need to be handled for IP mobility have been 245 thoroughly discussed in section 5 of the architectural 246 specification[7]. Please go through that section first before going 247 through the rest. 249 2.2. Selection of source and destination address 251 If a source network is connected with 'n' service providers and the 252 destination network is connected with 'm' service providers, there 253 will be a possible 'm*n' combination of source-destination pairs for 254 connection between source and destination. So, application program 255 needs to select a source and destination address before initiating 256 communication with the destination. 258 A system call needs to be introduced to get the source address based 259 on the destination address. If application program needs to use the 260 destination address directly, it needs to use this system call. 262 int getcommaddr(int sockfd, struct in_addr *dst, struct addr_pair 263 *endpts); 265 'addr_pair' holds the addresses of communication end points as 266 follows: 268 struct addr_pair { 269 struct in_addr src; 270 struct in_addr dst; 271 }; 273 'getcommaddr' returns the number of source-destination pairs for 274 communication; the field 'endpt' will hold the array of these 275 addresses. The array will be in sorted manner based on the best 276 possible route. 'sockfd' is used to get the 'type of service' 277 assigned. So, an application program needs to set its type of service 278 before using this call. 280 Users may use name instead of IP address to reach the destination. A 281 new system call needs to be introduced 'gethostbynamewithsrcaddr', 282 which is an extension to 'gethostbyname' as follows: 284 struct hostent *gethostbynamewithsrcaddr(int sockfd,const char *name, 285 int *nroutes, struct addr_pair *endpts); 287 'gethostbynamewithsrcaddr' takes 'name' and 'sockfd' as input 288 parameters and finds out the best possible route to reach the 289 destination. It returns the pointer to the 'hostent' structure as 290 returned by 'gethostbyname' system call. The parameter 'nroutes' 291 gets the number of possible routes to be used and the corresponding 292 source and destination addresses gets assigned to 'endpts' in sorted 293 manner. 'sockfd' is used to get the 'type of service' assigned. So, 294 an application program needs to set its type of service before using 295 this call. 297 An application program needs to use these source addresses from the 298 top (i.e. the 0th) to establish connection with the destination. It 299 needs to bind source address 'src' and then connect with the 300 destination address 'dst'. 302 2.2.1. Path selection 304 Paths are selected by sending RSVP messages from user to the PE 305 routers using MPLS UNI[12] with the following changes in respective 306 modules. 308 In order to transport a packet from one network to another, provider 309 network sets up a LSP. In RSVP[10,11], resource reservation is 310 receiver-initiated. In the Path message, the sending application 311 construct Path message using RSVP SENDER_TSPEC and ADSPEC objects. 312 The path properties of ADSPEC object gets modified by the network 313 elements as the Path message moves from sender to receiver. The 314 receiver makes use of SENDER_TSPEC and ADSPEC objects and forms 315 FLOWSPEC object and sends back to the network element towards the 316 sender. In order to make decision which path an application should 317 select from multiple possible paths due to multihoming, ADSPEC object 318 that was received by the receiver has to be passed back to the sender 319 by appending them with the Resv message. 321 For best effort service, path is selected based on widest-shortest 322 path approach, i.e. the path having the maximum effective available 323 bandwidth with minimum NUMBER_OF_IS_HOPS. Effective available 324 bandwidth is calculated as 326 bandwidth allocated to the customer 327 ----------------------------------------- * AVAILABLE_PATH_BANDWIDTH 328 gross effective bandwidth allocated to customers 330 If (Effective available bandwidth > unused bandwidth 331 allocated to the customer) 332 Effective available bandwidth = unused bandwidth 333 allocated to the customer. 335 When a Path message is sent from a user to the ingress PE router, for 336 best-effort service the PE router sets up a LSP with the egress PE 337 router and stores the path attributes with the ADSPEC objects if no 338 LSP has already been created. The ingress PE router sends the path 339 attributes (with AVAILABLE_PATH_BANDWIDTH set as Effective available 340 bandwidth) to the sender. If ingress PE router finds an existing LSP 341 for the destination node, it sends the path attributes associated to 342 the LSP. 344 PE routers need to maintain a list of customers that have accessed 345 the LSP with the last time of access. At the end of each RSVP refresh 346 time, it needs to check the list and delete those entries whose last 347 time of access exceeds the time period of RSVP refresh time. Gross 348 effective bandwidth is calculated as the sum of bandwidths allocated 349 to all the customers available in the list. 351 The above equation is applicable when communication takes place 352 between global unicast/multicast addresses. In case of VPN, service 353 providers allocate fixed bandwidth path between two customer 354 locations. So, when communication takes place between private 355 addresses actual unused bandwidth of that path has to be returned. 357 For Guaranteed bandwidth[14] and Controlled-Load service[13] path is 358 selected with MINIMUM_PATH_LATENCY with minimum NUMBER_OF_IS_HOPS, 359 also sender applications need to send PathTear messages for all the 360 paths that are not selected. 362 A PE router will be in a different address space than the address 363 space of the customer network. As hosts need not be aware of the PE 364 routers, hosts need to send queries to the CE router to get the 365 address of the PE router and store the same in their cache, the way 366 it works with DNS. 368 2.2.2. Link failure and switch over to an alternate route 370 As stated in section 2.1, there are possible "m*n" routes. Client 371 applications select any one of them for communication. If 372 communication fails due to link failure, it may be desirable to 373 switch over to an alternate route (application programs must ensure 374 that it conforms to the requirement of the application). 376 In reality link failure is a rare phenomenon; so detection of link 377 failure should not become an overhead for the network. Fault gets 378 detected first at the local site where the fault is associated with. 379 Say, if CE-PE link fails, it is the CE router that comes to know 380 about it at the beginning. So, the local site needs to take 381 initiative for the switchover operation. When failure happens, 382 system generates trap which triggers the operation for switchover to 383 an alternate route. 385 The steps can be summarized as follows: 387 o When client application calls 'getcommaddr' or 388 'gethostbynamewithsrcaddr' system finds out a list of possible 389 "source-destination" pairs for communication. If number of routes 390 happen to be more than one rest of the steps are followed. 392 o Client application establishes a TLS [5] session with its peer 393 after 5 unit tuple gets established. After handshake operation, 394 client application sends the list of source-destination pair to its 395 peer in secured mode. Exchange of routes is required because failure 396 may happen in the remote site too; 398 o Both client application and its peer store security parameters of 399 TLS session and the list of source-destination routes with the 400 protocol control block (PCB) using 'setsockopt' which informs the 401 system to activate switchover operation if there is a link failure; 403 o When CE router detects failure of CE-PE link, it broadcasts an ICMP 404 message ICMP_LINKFAILURE_CE_PE_LINK to all the hosts. 406 o On receiving ICMP_LINKFAILURE_CE_PE_LINK, system goes through the 407 list of PCB and gets the list of applications for which it needs to 408 start the switchover operation. For any such particular application, 409 it prepares the list of possible routes for communication through the 410 active links. It tries to set alternate route to its peer by sending 411 ICMP message ICMP_LINKFAILURE_SET_ALT_ROUTE in secured mode with the 412 best possible route. 414 o On receiving ICMP_LINKFAILURE_SET_ALT_ROUTE, peer host checks 415 whether there is any application in the list of PCB where the request 416 will be applicable. On finding the right PCB, it sets the alternate 417 route and sends a message ICMP_LINKFAILURE_ALT_ROUTE_ESTABLISHED to 418 its peer. 420 o On receiving ICMP_LINKFAILURE_ALT_ROUTE_ESTABLISHED, system sets 421 the alternate route and completes the operation of switchover. 423 So, it introduces an ICMP message of type ICMP_LINKFAILURE (type 41) 424 with the following codes: 425 ICMP_LINKFAILURE_CE_PE_LINK 1 426 ICMP_LINKFAILURE_CE_FAILURE 2 427 ICMP_LINKFAILURE_SET_ALT_ROUTE 3 428 ICMP_LINKFAILURE_ALT_ROUTE_ESTABLISHED 4 430 In order to provide secured communication it needs to depend on 431 security protocol SSL/TLS. Security parameters e.g. secret key, 432 compression method and cipher spec are stored in the PCB. ICMP 433 messages will have two parts; information in the first part, i.e. 434 'struct icmp' will hold all the necessary information to locate the 435 connection entry in the list of PCB. The second part will hold the 436 information related to the operation and will be in encrypted form 437 with record header. So, changes within a PCB entry is allowed only 438 if ICMP message is received in a secured mode. 440 It introduces an element 'struct id_pcb' inside union 'icmp_dun' of 441 'struct icmp' as follows: 443 struct icmp { 444 u_char icmp_type; /* type of message, see below */ 445 u_char icmp_code; /* type sub code */ 446 u_short icmp_cksum; /* ones complement cksum of struct */ 447 union { 448 u_char ih_pptr; /* ICMP_PARAMPROB */ 449 struct in_addr ih_gwaddr; /* ICMP_REDIRECT */ 450 struct ih_idseq { 451 uint16_t icd_id; /* network format */ 452 uint16_t icd_seq; /* network format */ 453 } ih_idseq; 454 int ih_void; 455 /* ICMP_UNREACH_NEEDFRAG -- Path MTU Discovery (RFC1191) */ 456 struct ih_pmtu { 457 uint16_t ipm_void; /* network format */ 458 uint16_t ipm_nextmtu; /* network format */ 459 } ih_pmtu; 460 struct ih_rtradv { 461 u_char irt_num_addrs; 462 u_char irt_wpa; 463 u_int16_t irt_lifetime; 464 } ih_rtradv; 465 } icmp_hun; 466 union { 467 struct id_ts { /* ICMP Timestamp */ 468 uint32_t its_otime; /* Originate */ 469 uint32_t its_rtime; /* Receive */ 470 uint32_t its_ttime; /* Transmit */ 471 } id_ts; 472 struct id_ip { 473 struct ip idi_ip; 474 /* options and then 64 bits of data */ 475 } id_ip; 476 struct id_pcb { 477 u_char ipcb_ip_proto; /* protocol TCP/UDP */ 478 struct in_addr ipcb_laddr, /* source address */ 479 ipcb_faddr; /* destination address */ 480 u_short ipcb_lport, /* source port */ 481 ipcb_fport; /* destination port */ 482 } id_pcb; 483 struct icmp_ra_addr id_radv; 484 u_int32_t id_mask; 485 char id_data[1]; 486 } icmp_dun; 487 }; 489 'struct inpcb' of protocol control block includes four new fields 490 'inp_lf_n_routes', 'inp_lf_stat', 'inp_lf_routes' and 491 'inp_seq_params' of type SecParams (SecParams is a type of struct 492 whose elements are elements of SecurityParameters as defined in 493 section 6.1 of RFC5246 [5]) as follows: 495 struct inpcb { 496 struct inpcb *inp_next, *inp_prev; /* doubly linked list */ 497 struct inpcb *inp_head; /* pointer back to chain of inpcb's for 498 this protocol */ 499 struct in_addr inp_faddr; /* foreign IP address */ 500 u_short inp_fport; /* foreign port# */ 501 struct in_addr inp_laddr; /* local IP address */ 502 u_short inp_lport; /* local port# */ 503 struct in_addr inp_fcladdr;/* foreign care-of address */ 504 struct in_addr inp_lcladdr;/* local care-of address */ 505 struct in_addr inp_hagentaddr; /* address of home agent */ 506 struct socket *inp_socket; /* back pointer to socket */ 507 caddr_t inp_ppcb; /* pointer to per-protocol pcb */ 508 struct route inp_route /* placeholder for routing entry */ 509 int inp_flags; /* generic IP/datagram flags */ 510 struct ip inp_ip; /* header prototype; should have more */ 511 struct mbuf *inp_options;/* IP options */ 512 struct ip_moptions *inp_moptions; /* IP multicast options */ 513 u_char inp_lf_n_routes; /* number of possible routes */ 514 u_char inp_lf_stat; /* state of switchover; 515 STAT_DO_NOT_ALTER(0)/STAT_ALTER(1) */ 516 struct addr_pair *inp_lf_routes;/*pointer to the array of routes*/ 517 SecParams inp_seq_params;/* security parameters */ 518 }; 520 From application layer, the field 'inp_seq_params' is set with the 521 system call 'setsockopt' by introducing a new socket option 522 SO_SEQPARAM of level SOL_SOCKET; route information i.e. 523 inp_lf_n_route, inp_lf_routes and inp_lf_stat are set by system call 524 'setsockopt' by introducing another socket option SO_LFROUTES of 525 level SOL_SOCKET. 527 setcockopt (sockfd, SOL_SOCKET, SO_SEQPARAM, (char *)&seq_param, 528 sizeof(SecurityParameters)); 530 setsockopt (sockfd, SOL_SOCKET, SO_LFROUTES, (char *)routes, sizeof 531 (struct addr_pair)*n_routes); 532 ICMP messages with 'icmp_code' ICMP_LINKFAILURE_SET_ALT_ROUTE and 533 ICMP_LINKFAILURE_ATL_ROUTE_ESTABLISHED will have same format as 534 follows: 536 Information of the current active link of the PCB entry i.e. protocol 537 id, source address, destination address, source port and destination 538 port are set with the fields of 'struct id_pcb' of 'struct icmp'. The 539 encrypted part of the message will have three fields, source address 540 and destination address of the alternate route and ICMP code (i.e. 541 ICMP_LINKFAILURE_SET_ALT_ROUTE/ 542 ICMP_LINKFAILURE_ALT_ROUTES_ESTABLISHED) as it was set with the ICMP 543 header. 545 Recipient of these messages needs to search PCB entry in the 546 following manner: 548 If 'source port', 'destination port' and 'protocol id' of incoming 549 ICMP message matches with any entry in the list of PCB and the fields 550 'source address' and 'destination address' of the ICMP message 551 matches with any entry of 'inp_lf_routes' of the corresponding entry 552 in the PCB, it will be considered as a match. If no matching entry is 553 found, message has to be dropped. With the security information of 554 the PCB entry, the encrypted part of the ICMP message gets decrypted. 555 If it fails to decrypt the message or the message received with 556 invalid MAC, message needs to be dropped. If ICMP code in the header 557 does not match with that of the encrypted part, the message also 558 needs to be dropped. 560 Details of the ICMP operations are described below: 562 ICMP_LINKFAILURE_CE_PE_LINK 564 CE router detects link failure and sends this message to all the 565 users in the network; The field 'icmp_gwadd' of 'struct icmp' holds 566 the IP address of the PE router. 568 ICMP_LINKFAILURE_CE_FAILURE 570 CE router itself may fail. It gets detected by alternate CE router. 571 CE routers send keep-alive messages between themselves at regular 572 interval to detect this failure. The field 'icmp_gwadd' of 'struct 573 icmp' holds the IP address of the faulty CE router. 575 ICMP_LINKFAILURE_SET_ALT_ROUTE 577 This message is sent by a host after receiving ICMP broadcast message 578 ICMP_LINKFAILURE_CE_PE_LINK or ICMP_LINKFAILURE_CE_FAILURE from a CE 579 router for all the entries of PCB whose ('inp_lf_stat' = STAT_ALTER 580 and source-destination route passes through the failed link), to 581 their peer. It maintains a list of information where each entry will 582 have the connection details including the best possible route. For 583 best effort traffic route is selected by sending echo messages and 584 calculating round trip delay; for the rest it follows the approach 585 stated in section 2.1.1. For each entry in the list, host sends 586 ICMP_LINKFAILURE_SET_ALT_ROUTE for (arbitrary) 'n' number of times 587 with an (arbitrary) interval of 't' msecs (sufficient enough for the 588 reply of ICMP_LINKFAILURE_SET_ALT_ROUTE comes back and gets 589 processed; roughly twice the round trip delay) till it receives a 590 positive acknowledgment ICMP_LINKFAILURE_ATL_ROUTE_ESTABLISHED from 591 its peer. On receiving a positive acknowledgment 592 ICMP_LINKFAILURE_ATL_ROUTE_ESTABLISHED, it deletes the corresponding 593 entry from the list and updates the route information in the PCB. 595 ICMP_LINKFAILURE_ATL_ROUTE_ESTABLISHED 597 On receiving ICMP_LINKFAILURE_SET_ALT_ROUTE, host needs to look for a 598 match in the PCB. If there is a match, host sends 599 ICMP_LINKFAILURE_ATL_ROUTE_ESTABLISHED to its peer on successful 600 completion of changing 'source address' and 'destination address' 601 with the desired value of the alternate route in the PCB. The message 602 will contain all the fields as that of the receiving message by 603 setting 'icmp_code' as ICMP_LINKFAILURE_ATL_ROUTE_ESTABLISHED both at 604 the header part as well as at the encrypted part. 606 Switchover operation requires some amount of time. This duration is 607 under the tolerance limit for best effort traffic. For Guaranteed 608 bandwidth and Controlled-Load service as the circuit needs to be 609 reestablished, it may cause flicker. This situation can be avoided 610 by maintaining back-up circuit through an alternate route. As link 611 failure is a rare phenomenon, this feature can be provided on on- 612 demand basis or based on the application type. 614 2.3. Implementation aspects 616 Following changes are expected with the source code of BSD. 618 Introduce ip_domain structure and some parameters as follows: 620 struct ip_domain { 621 struct in_addr net_addr; 622 struct in_addr net_mask; 623 struct in_addr def_router; 624 }; 625 #define MAX_IP_DOMAINS 16 626 short num_ipdomains; 627 struct ip_domain *ipdomain[MAX_IP_DOMAINS]; 629 If customer network maintains private IP domain (along with the user- 630 id space provided by the service providers) and expects its 631 communication to be confined within its own space, 'def_router' has 632 to be set as NULL. 634 Upload IP domain information for all of its IP domains during system 635 start up. These domain information can be uploaded through router 636 advertisement or through DHCP. The domain information should contain 637 the next hop address to reach the corresponding default router as 638 well. 640 There has to be a provision to upload these information through 641 'sysctl' to configure them manually. 643 Three new 'sysctl' routines have to be introduced under the 'ip' node 644 of the MIB tree (i.e. under CTL_NET, PF_INET, IPPROTO_IP) 645 IPCTL_NUM_DOMAINS, IPCTL_DOMAIN and IPCTL_USE_HOMEADDR (applicable 646 for mobile node). Both IPCTL_NUM_DOMAINS and IPCTL_USE_HOMEADDR are 647 of type CTLTYPE_INT and IPCTL_DOMAIN is of type CTLTYPE_NODE. Using 648 'sysctl' IPCTL_NUM_DOMAINS has to be configured first. Configuration 649 of IPCTL_NUM_DOMAINS has to populate IPCTL_NUM_DOMAIN entries of 650 nodes under IPCTL_DOMAIN and for each of these nodes three MIB 651 attributes DOMAIN_NET_ADDR, DOMAIN_NET_MASK and DOMAIN_DEF_ROUTER 652 (each of type CTLTYPE_NODE) has to be allocated. 654 All the routers as well as hosts that are having interfaces 655 connecting to multiple subnets need to be configured through 656 'sysctl'. 658 Mobile users should get provision to change IPCTL_USE_HOMEADDR 659 attribute dynamically. 661 Add a route entry for all the default routers during system start up. 663 2.3.1. Processing of system call 'getcommaddr' 665 Introduce a routine (say 'getendpointaddr') that will find out a list 666 of source-destination addressees sorted in order based on sending 667 Path messages between a list of source addresses to a list of 668 destination addresses. The routine should select the service type 669 based on the type of service field (which can be obtained by calling 670 'getsockopt' with the socket id 'sockfd' passed as a parameter). 672 System call 'getcommaddr' has to be processed in the following 673 manner: 675 If destination address of the IP packet falls outside of its 676 IP domains { 677 If destination address is from private address space { 678 if the host is having only one interface { 679 for each private address assigned to the interface get 680 an entry for the source list. 681 } 682 else { 683 for all the default routers { 684 use 'rtalloc' to get the next hop address for the 685 default router. 687 get an entry for the source list based on 688 the outgoing interface 'ia', and the private 689 address associated with the default router. 690 } 691 } 692 destination list will have a lone entry with the 693 destination private address. 694 } 695 else { 696 If destination address is provider independent { 697 call 'getmappedaddr' to get all the associated PA addresses; 698 for each PA address get an entry of the destination list 699 } 700 else { 701 get a lone entry for the destination list with the 702 destination address. 703 } 705 If user has selected its "Home Address" { 706 /*Applicable to IP mobility*/ 707 get a lone entry in the source list with the "Home Address". 708 } 709 else { 710 if the host is having only one interface { 711 for each global unicast address of the interface, 712 get an entry for the source list. 713 } 714 else { 715 for all the default routers { 716 use 'rtalloc' to get the next hop address for the 717 default router. 719 get an entry for the source list based on 720 the outgoing interface 'ia', and the global unicast 721 address associated with the default router. 722 } 723 } 724 } 726 } 727 call 'getendpointaddr' to get the list of source-destination 728 addresses in sorted manner. 729 } 730 else { /* i.e. destination address is inside its IP domains */ 731 use 'rtalloc' to get the next hop address for the 732 destination address. 734 if destination address is a link local address { 735 select source address based on the outgoing interface 736 and the link local address assigned to it. 737 } 738 else { 739 select source address based on the outgoing interface 740 and the domain that the destination address belongs to. 741 } 742 there is only one possible source-destination combination. 743 } 745 2.3.2. Processing of 'gethostbynamewithsrcaddr' 747 System call 'gethostbynamewithsrcaddr' has to be processed in the 748 following manner: 750 This is an enhancement of the system call 'gethostbyname'. 751 'gethostbyname' calls three routines that performs host table search, 752 NIS search and DNS search. Once name is resolved, following additions 753 are expected to resolve source-destination pair. 755 If 'hostent' structure contains addresses which are inside its IP 756 domains { 757 if 'hostent' structure contains a private address { 758 Assign destination address as a private address 759 contained in 'hostent'; 761 use 'rtalloc' to get the next hop address for the 762 destination address. 764 select source address based on the outgoing interface 765 and the domain that the destination address belongs to. 766 } 767 else { 768 Select a global unicast address contained in 'hostent' for 769 destination address. 771 use 'rtalloc' to get the next hop address for the 772 destination address. 774 select source address based on the outgoing interface 775 and the domain that the destination address belongs to. 776 } 777 there is only one possible source-destination combination. 778 } 779 else { 780 if 'hostent' structure contains private address { 781 if host is having only one interface { 782 for each private address assigned to the interface get 783 an entry for the source list. 784 } 785 else { 786 for all the default routers { 787 use 'rtalloc' to get the next hop address for the 788 default router. 790 get an entry for the source list based on 791 the outgoing interface 'ia', and the private 792 address associated with the default router. 793 } 794 } 795 for each private address in the 'hostent' structure 796 get an entry for the destination list. 797 } 798 else { 799 for each PA address in the 'hostent' structure 800 get an entry for the destination list. 802 if user has selected its "Home Address" { 803 /*Applicable only to IP mobility */ 804 get a lone entry in the source list with the "Home Address". 805 } 806 else { 807 if the host is having only one interface { 808 for each global unicast address of the interface, 809 get an entry for the source list. 810 } 811 else { 812 for all the default routers { 813 use 'rtalloc' to get the next hop address for the 814 default router. 816 get an entry for the source list based on 817 the outgoing interface 'ia', and the global unicast 818 address associated with the default router. 819 } 820 } 821 } 823 } 824 call 'getendpointaddr' to get the list of source-destination 825 addresses in sorted manner. 826 } 828 2.3.3. Changes required in ip_output and ip_forwarding modules 830 Execute the following steps in the 'ip_output' routine of the IP 831 stack before it calls 'rtalloc' for route look up. 833 If destination address of the IP packet falls outside of its 834 IP domains { 835 get def router address based on the IP domain 836 the source address belongs to. 838 use 'rtalloc' to get the next hop address for the def router. 840 Forward the packet to the next hop. 841 } 842 else { /* i.e. destination address is inside its IP domains */ 843 follow the usual procedure to forward packets 844 } 846 In BSD, the 'ip_forwarding' routine calls 'ip_output'; so it should 847 be left as it is. 849 2.3.4. Processing of protocol input routines and socket IO system calls 851 Protocol input routines need to locate the socket/process in the 852 usual manner with the 5 unit tuple (i.e. protocol, source address, 853 source port, destination address, destination port). 855 When a packet is received by a mobile node (at a foreign site), it 856 can be received in two modes. It can be received directly from the 857 correspondent node with the 'destination address' as the co-located 858 care-of address and its home address in the IP stack (see section 4.1 859 of RFC6275[8]). In the second mode the packet can be received via the 860 home agent using IP over IP. Once the IP layer receives a packet with 861 IP over IP, it is supposed to strip off the outer header before 862 passing the packet to the protocol input routine. In this case 863 packet will be received by the protocol input routine with 864 destination address as the home address of the mobile node with no 865 information related to its care-of address. So, protocol input 866 routine needs to check whether the destination address of the 867 received packet belongs to any one of its IP domains. If it does 868 not, it needs to find out the co-located care-of address by going 869 through the interface list if it is not already found in the packet 870 received. This information is needed by the TCP input routine while 871 processing a SYN message. It is also needed by the UDP/RAW modules 872 while processing the system call 'recvwithdstaddr'. 874 While processing the output routines like 'sendwithsrcaddr', 875 'sendto', UDP/RAW modules needs to check the parameters related to 876 source address, source port, destination address, destination port, 877 care-of address of the source, care-of address of the destination in 878 the protocol control block. Parameters in the PCB should prevail over 879 parameters passed by the system call while forming the IP packet. 881 2.4. Multihoming and VPN 883 For a corporate, that maintains multiple offices and communicates 884 within themselves through private address space using VPN needs to 885 distribute its entire private address space to all its site in a 886 suitable manner. Each one of its offices will get multiple private 887 address space where each of them will be associated with a particular 888 link. Let us consider one of its offices gets connected to two 889 providers P1 and P2 and gets address space as 890 'unicastNetAddr1'/'unicastNetMask1' and 891 'unicastNetAddr2'/'unicastNetMask2' respectively. It also gets 892 assigned private address space from its corporate as 893 'privateDomainNetAddr1'/'privateDomainNetMask1' and 894 'privateDomainNetAddr2'/'privateDomainNetMask2' which will be 895 associated with the CE routers CE1 and CE2 respectively. 897 All hosts as well as the intermediate routers will have four entries 898 of ip_domain: 900 1: 'net_addr = 'unicastNetAddr1' 901 'net_mask = 'unicastNetMask1' 902 'def_router = CE1 903 2: 'net_addr = 'unicastNetAddr2' 904 'net_mask = 'unicastNetMask2' 905 'def_router = CE2 906 3: 'net_addr' = 'privateDomainNetAddr1' 907 'net_mask' = 'privateDomainNetMask1' 908 'def_router' = CE1 909 4: 'net_addr' = 'privateDomainNetAddr2' 910 'net_mask' = 'privateDomainNetMask2' 911 'def_router' = CE2 913 2.5. IP Address Stacking 915 IP address stacking in IPv6 is performed with the approach introduced 916 in section 6.4 of RFC6275[8] with slight modification. RFC6275 917 describes how to pass "Home Address" as well as co-located care-of 918 address of the destination address if it happen to be mobile. The 919 same approach has been extended to support IP address stacking for 920 the source address and to support IP address stacking for both source 921 address as well as destination address. The "Reserved" space in the 922 type 2 routing header has been split into two parts; an one octet 923 field to address the "Stacking Type" and the rest 3 octets are left 924 as Reserved. 926 Stacking Type is interpreted as follows: 928 Stacking Type=0 929 Source Address: Address of the sender. 930 Destination Address: co-located care-of address of the receiver. 931 Address 1: Home Address of the receiver. 932 Hdr Ext Len=2. 934 So, type 2 routing header for stacking type 0 will be as follows: 936 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 937 | Next Header | Hdr Ext Len=2 | Routing Type=2|Segments Left=1| 938 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 939 |Stacking Type=0| Reserved | 940 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 941 | | 942 + + 943 | | 944 + Address 1:Home Address of the receiver + 945 | | 946 + + 947 | | 948 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 950 Stacking Type=1 951 Source Address: co-located care-of address of the sender. 952 Destination address: Address of the receiver. 953 Address 1: Home Address of the sender. 954 Hdr Ext Len=2. 956 So, type 2 routing header for stacking type 1 will be as follows: 958 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 959 | Next Header | Hdr Ext Len=2 | Routing Type=2|Segments Left=1| 960 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 961 |Stacking Type=1| Reserved | 962 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 963 | | 964 + + 965 | | 966 + Address 1:Home Address of the sender + 967 | | 968 + + 969 | | 970 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 972 Stacking Type 2 973 Source Address: co-located care-of address of the sender. 974 Destination Address: co-located care-of address of the receiver. 975 Address 1: Home Address of the sender. 976 Address 2: Home Address of the receiver. 977 Hdr Ext Len=4. 979 So, type 2 routing header for stacking type 2 will be as follows: 981 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 982 | Next Header | Hdr Ext Len=4 | Routing Type=2|Segments Left=1| 983 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 984 |Stacking Type=2| Reserved | 985 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 986 | | 987 + + 988 | | 989 + Address 1:Home Address of the sender + 990 | | 991 + + 992 | | 993 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 994 | | 995 + + 996 | | 997 + Address 2:Home Address of the receiver + 998 | | 999 + + 1000 | | 1001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1003 Next Header 1004 8-bit selector. Identifies the type of header immediately 1005 following the routing header. Uses the same values as the IPv6 1006 Next Header field [9]. 1008 Hdr Ext Len 1009 4 (8-bit unsigned integer); length of the routing header in 8- 1010 octet units, not including the first 8 octets. 1012 Routing Type 1013 2 (8-bit unsigned integer). 1015 Segments Left 1016 1 (8-bit unsigned integer). 1018 Stacking Type 1019 2 (8-bit unsigned integer). 1021 Reserved 1022 24-bit reserved field. The value MUST be initialized to zero by 1023 the sender, and MUST be ignored by the receiver. 1025 Address 1 1026 Home Address of the sender. 1028 Address 2 1029 Home Address of the receiver. 1031 IP address stacking in IPv4 is performed by introducing new IP option 1032 under the option class "Datagram or Network Control", i.e. 0. The 1033 option number is 16. The CODE(144) field is followed by one octet 1034 field "Stacking Type" followed by two octet reserved space (NULL) as 1035 padding followed by the address fields based on the Stacking Type. 1037 Stacking Type is interpreted as follows: 1038 Stacking Type=0 1039 Source Address: Address of the sender. 1040 Destination Address: co-located care-of address of the receiver. 1041 Address 1: Home Address of the receiver. 1042 Header Length:7 1044 Format of IP address stacking option with stacking type 0 1045 in the IP header will be as follows: 1047 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1048 | CODE(144) |Stacking Type=0| Reserved | 1049 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1050 + Address 1:Home Address of the receiver + 1051 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1053 Stacking Type=1 1054 Source Address: co-located care-of address of the sender. 1055 Destination Address: Address of the receiver. 1056 Address 1: Home Address of the sender. 1057 Header Length:7 1059 Format of IP address stacking option with stacking type 1 1060 in the IP header will be as follows: 1062 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1063 | CODE(144) |Stacking Type=1| Reserved | 1064 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1065 + Address 1:Home Address of the sender + 1066 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1068 Stacking Type=2 1069 Source Address: co-located care-of address of the sender. 1070 Destination Address: co-located care-of address of the receiver. 1071 Address 1: Home Address of the sender. 1072 Address 2: Home Address of the receiver. 1073 Header Length:8 1075 Format of IP address stacking option with stacking type 2 1076 in the IP header will be as follows: 1078 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1079 | CODE(144) |Stacking Type=2| Reserved | 1080 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1081 + Address 1:Home Address of the sender + 1082 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1083 + Address 2:Home Address of the receiver + 1084 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1086 3. Security Consideration 1088 This document provides a solution for site multihoming of stub networks. 1089 Message exchange between source and destination related to link failure 1090 has to be done in secured mode as explained in section 2.1.2. For common 1091 security related issues that any site may experience, one needs to 1092 consult with the "Site Security Handbook", RFC2196[6]. For issues 1093 related to IP Mobility, section 5 of RFC5944[4] has to be consulted. 1095 4. IANA Consideration 1097 This draft does not request any action from IANA. 1099 5. Normative References 1101 [1] J. Abley, B. Black, V. Gill, "Goals for IPv6 Site-Multihoming 1102 Architectures", RFC3582, August 2003. 1104 [2] R. Braden, "Requirements for Internet Hosts -- Communication 1105 Layers", RFC1122, October 1989. 1107 [3] R. Hinden, S. Deering, "IP Version 6 Addressing Architecture.", 1108 RFC4291, February 2006. 1110 [4] C. Perkins, "IP Mobility Support for IPv4, Revised", RFC5944, 1111 November 2010. 1113 [5] T. Dierks, E. Rescorla, "The Transport Layer Security (TLS) 1114 Protocol Version 1.2", RFC5246, August 2008. 1116 [6] B. Fraser, "Site Security Handbook", RFC2196, September 1997. 1118 [7] S. Bandyopadhyay, "An Architectural Framework of the Internet 1119 for the Real IP World" 1120 (work in progress). 1121 [8] C. Perkins, Ed., D. Johnson, J. Arkko, "Mobility Support in 1122 IPv6" RFC 6275, July 2011. 1124 [9] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 1125 Specification", RFC 2460, December 1998. 1127 [10] L. Zhang, S. Berson, S. Herzog, S. Jamin, "Resource ReSerVation 1128 Protocol (RSVP) -- Version 1 Functional Specification", RFC 1129 2205, September 1997. 1131 [11] D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, G. 1132 Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", 1133 RFC 3209, December 2001. 1135 [12] G. Swallow, J. Drake, H. Ishimatsu, Y. Rekhter, "Generalized 1136 Multiprotocol Label Switching (GMPLS) User-Network Interface 1137 (UNI): Resource ReserVation Protocol-Traffic Engineering 1138 (RSVP-TE) Support for the Overlay Model", RFC 4208, 1139 October 2005. 1141 [13] J. Wroclawski, "Specification of the Controlled-Load Network 1142 Element Service", RFC 2211, September 1997. 1144 [14] S. Shenker, C. Partridge, R. Guerin, "Specification of 1145 Guaranteed Quality of Service", RFC 2212, September 1997. 1147 6. Informative References 1149 [15] P. Srisuresh, K. Egevang, "Traditional IP Network Address 1150 Translator (Traditional NAT)", RFC3022, January 2001. 1152 7. Author's Address 1154 Shyamaprasad Bandyopadhyay 1155 HL No 205/157/7, Kharagpur 721305, India 1156 Phone: +91 3222 225137 1157 e-mail: shyamb66@gmail.com