idnits 2.17.1 draft-shyam-real-ip-framework-30.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 : ---------------------------------------------------------------------------- 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 date (April 11, 2017) is 2565 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '11' is defined on line 1034, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 1037, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 1040, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 1043, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 1045, but no explicit reference was found in the text == Unused Reference: '16' is defined on line 1048, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4893 (ref. '4') (Obsoleted by RFC 6793) -- Obsolete informational reference (is this intentional?): RFC 1771 (ref. '12') (Obsoleted by RFC 4271) -- Obsolete informational reference (is this intentional?): RFC 1883 (ref. '13') (Obsoleted by RFC 2460) -- Obsolete informational reference (is this intentional?): RFC 2460 (ref. '15') (Obsoleted by RFC 8200) Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT S. Bandyopadhyay 3 draft-shyam-real-ip-framework-30.txt April 11, 2017 4 Intended status: Informational 5 Expires: October 11, 2017 7 An Architectural Framework of the Internet for the Real IP World 8 draft-shyam-real-ip-framework-30.txt 10 Abstract 12 This document tries to propose an architectural framework of the 13 internet in the real IP world. It shows how to reorganize the 14 provider network with a large address space. It describes how a 15 three-tier mesh structured hierarchy can be established based on 16 fragmenting the entire space into some regions and some sub regions 17 inside each of them. It addresses issues which could be relevant to 18 this architecture in the context of IPv6. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on October 11, 2017. 37 Copyright Notice 39 Copyright (c) 2017 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. 49 Table of Contents 50 1. Introduction.....................................................2 51 2. Background.......................................................3 52 3. A Three tier mesh structured hierarchical network................4 53 3.1. Route propagation...........................................5 54 3.2. Determination of prefix lengths.............................7 55 3.2.1. A pseudo optimal distribution of prefixes in 56 a 64bit architecture.................................8 57 3.2.2. Whether to go for a two tier or three tier hierarchy 58 .....................................................9 59 3.3. Issues related to Satellite communications.................10 60 4. Provider Independent addressing, name services and multihoming..11 61 4.1. PI address Resolution......................................12 62 5. Issues related to IP mobility...................................15 63 5.1. Changes expected with the specifications related 64 to IP mobility.............................................17 65 6. Refinements over existing IPv6 specification....................18 66 7. Distributed processing and Multicasting.........................20 67 8. Transition to real IP from private IP...........................20 68 9. IANA Consideration..............................................21 69 10. Security Consideration.........................................21 70 11. Acknowledgments................................................21 71 12. Normative References...........................................21 72 13. Informative References.........................................22 73 14. Author's Address...............................................22 75 1. Introduction 77 Transition from IPv4 to IPv6 is in the process. Work has been done to 78 upgrade individual nodes (workstations) from IPv4 to IPv6. Also, 79 there are established documents to make routers/switches to work to 80 support IPv4 as well as IPv6 packets simultaneously in order to make 81 the transition possible [1]. CIDR[2] based hierarchical architecture 82 in the existing 32-bit system is supposed to be continued in IPv6 too 83 with a large address space. There are documents/concerns over BGP 84 table entries to become too large in the existing system [3]. There 85 are proposals to upgrade Autonomous System number to 32-bit from 86 16-bit to support the demand at the same time [4]. The challenge 87 relies on how to make the transition smooth from IPv4 to a real IP 88 world with least changes possible. 90 The term "real IP environment" is referred to an environment where 91 hosts in a customer network will possess globally unique IP addresses 92 and communicate with the rest of the world without the help of 93 NAT[5]. This document reflects changes required with the BSD 4.4 94 source code where ever applicable. 96 2. Background 98 Existing system is in work with Autonomous System (AS) and inter-AS 99 layer with the approach of CIDR. In order to meet the need within the 100 32-bit address space, Autonomous Systems of various sizes maintain 101 CIDR based hierarchical architecture. With the help of NAT [5], a 102 stub network can maintain an user ID space as large as a class A 103 network and can meet its useful need to communicate with the rest of 104 the world with very few real IP addresses. With the combination of 105 CIDR and NAT applied in the entire space, most of the part of 32-bit 106 address space gets effectively used as network ID. If the same gets 107 continued with a larger network ID, load in the switches will become 108 too high. 110 With traditional CIDR based hierarchy, a node of higher prefix can be 111 divided into number of nodes with lower prefixes. Each divided node 112 can further be subdivided with nodes of further lower prefixes. This 113 process can be continued till no further division is possible. The 114 point worth noting is at each point the designer of the network has 115 to preconceive the future expansion of the network with the concept 116 in the mind that the resource can not be exhausted at any point of 117 time. This phenomenon leads the designer to allocate resources much 118 higher than whatever is needed which leads to a space of unused 119 address space and the concept of H-D (host-density) ratio comes into 120 play. The problem gets aggravated once resource gets exhausted by any 121 chance. e.g. a node of prefix /16 can be divided with a number of 122 nodes of prefixes /24. If any one of the nodes /24 gets exhausted, 123 resources of other nodes of prefixes /24 can not be used even if they 124 are available. 126 In IPv4 environment, there is a desperate attempt of the service 127 providers to provide internet services with the help of NAT. e.g. a 128 large educational institute meets its current requirement with 4 real 129 IP addresses; one for its mail server, one for its web server, one 130 for its ftp server and another one for its proxy server to provide 131 web based services to all of its users. These four types of services 132 are used by any organization of any size(it may be 400 or even 133 40000). In the current provider network these organizations are 134 supported their need with 4 IP addresses and the CIDR based tree has 135 been built using these components together. When private IP will be 136 replaced with real IP, each customer network will require IP 137 addresses based on its size and requirement. Transitioning to real IP 138 space with provider assigned addresses with CIDR based approach 139 itself without reorganization of the existing provider network may 140 not be a difficult task. This will continue with all the problems 141 associated with routing and problems related to distribution. Mesh 142 structured hierarchy is convenient to reduce the routing overhead as 143 well as for distribution of network resources in a suitable manner in 144 the long run. 146 3. A Three-tier mesh structured hierarchical network 148 As Autonomous Systems of various sizes are supported, Autonomous 149 Systems and the nodes inside the Autonomous Systems can be viewed as 150 graphically lying on the same plane within the address apace. If 151 network can be viewed as lying on different planes, routing issues 152 can be made simpler. If network is designed with a fixed length of 153 prefix for the Autonomous System everywhere, routing information for 154 the rest will get confined with the other part of the network prefix. 155 Which means the maximum size of AS gets assigned to all irrespective 156 of their actual sizes. This can be made possible with the advantage 157 of using a large address space and dividing it into number of regions 158 of fixed sizes inside it. Thus entire network can be viewed as a 159 network of inter-AS layer nodes. Each node in the inter-AS layer can 160 act either only as a router in the inter-AS layer or as a router in 161 the inter-AS layer with an Autonomous System attached to it with a 162 single point of attachment or as an Autonomous System with multiple 163 Autonomous System border routers (ASBR) appearing like a mesh. Thus 164 two tier mesh structured hierarchy gets established between AS layer 165 and inter-AS layer with each AS having a fixed length of prefix. 167 Based on the definition of Autonomous System, it is a small area 168 within the entire network that maintains its own independent identity 169 that communicates with the rest of the world through some specific 170 border routers. In the similar manner, if a larger area (say region 171 or state) can be considered as network of Autonomous Systems, that 172 can maintain its own identity by communicating with the rest of the 173 world through some border routers (say, state border router), mesh 174 structured hierarchy can be established within the inter-AS layer. 175 The inter-AS layer will be split into inter-AS-top and inter-AS- 176 bottom. To maintain this hierarchy, each node of inter-AS-top needs 177 to have multiple regional or state border routers (say, SBR) through 178 which each one will communicate with the rest of the world in the 179 similar manner an Autonomous System maintains ASBR. Thus, entire 180 network will appear as a network of nodes of inter-AS-top layer. To 181 maintain hierarchy, each node of the inter-AS-top needs to have a 182 fixed length of prefix. i.e. each node of the inter-AS top will be 183 assigned a maximum (fixed) number of nodes of Autonomous Systems. 185 Thus, with three-tier mesh structured hierarchy in the network layer, 186 network ID can be viewed as A.B.C. If pA, pB and pC be the prefix 187 lengths of inter-AS-top, inter-AS-bottom and AS layers respectively, 188 there will be 2^pA nodes at the topmost layer, 2^pB at the inter-AS- 189 bottom layer and 2^pC nodes at the AS layer. Thus the entire space 190 gets divided into a fixed number of regions and each region gets 191 divided into fixed number of sub regions. This division is supposed 192 to be made based on geography, population density and their demands 193 and related factors. 195 Let nMaxInterASTopNodes be the possible maximum number of nodes 196 assigned at the top most layer and nMaxInterASBottomNodes be that at 197 the inter-AS-bottom layer and nMaxASNodes at the AS layer. Where 198 nMaxInterASTopNodes <= 2^pA and nMaxInterASBottomNodes <= 2^pB and 199 nMaxASNodes <= 2^pC. 201 3.1. Route propagation 203 With hierarchy established, routing information that gets established 204 inside a node of inter-AS-top, does not need to be propagated to 205 another node of inter-AS-top. Entire routing information of inter-AS- 206 top layer needs to be propagated to inter-AS-bottom layer. So, each 207 router of inter-AS layer will have two tables of information, one for 208 the inter-AS-top and another for the inter-AS-bottom of the inter-AS- 209 top node that it belongs to. BGP (with little modification) will work 210 very well with a trick applied at the SBRs. Each SBR will not 211 propagate the routing information of inter-AS-bottom layer of its 212 domain to another SBR of neighboring domain. i.e. SBR of one top 213 layer node will propagate routing information only of inter-AS-top 214 layer to SBR of another top layer node. Inside a node of inter-AS- 215 top, routing information of inter-AS-top and inter-AS-bottom need to 216 be propagated from one ASBR to another neighboring ASBR. Inside a top 217 layer node A, routing information of another top layer node B will 218 have two parts; one for the list of SBRs through which a packet will 219 traverse from top layer node A to B and another for the list of ASBRs 220 through which the packet will traverse from one AS to another inside 221 A. In terms of BGP, AS_PATH attribute will be split into two parts; 222 one for the information of the top layer and another for the bottom 223 layer. Within the same node A routing information of one AS to 224 another AS will not have any top layer information. i.e. the top 225 layer information will be set to as NULL. 227 Similarly, each node of the AS layer will have three tables of 228 routing entries. One for the inter-AS-top, one for the inter-AS- 229 bottom and another for the routing information inside the Autonomous 230 System itself. 232 Introduction of hierarchy at the inter-AS layer reduces the size of 233 the routing table substantially. With the availability of hardware 234 resources if flat address space is maintained at each layer, problems 235 related to CIDR can be avoided. With flat address space, no 236 hierarchical relationship needs to be established between any two 237 nodes in the same layer. So, all the nodes inside each layer can be 238 used till they get exhausted. With flat address space (i.e. without 239 prefix reduction), BGP tables will have maximum nMaxInterASTopNodes + 240 nMaxInterASBottomNodes entries. 242 IGP like OSPF has got provision to divide AS into smaller areas. OSPF 243 hides the topology of an area from the rest of the Autonomous System. 244 This information hiding enables a significant reduction in routing 245 traffic. With the support of subnetting, OSPF attaches an IP address 246 mask to indicate a range of IP addresses being described by that 247 particular route. With this approach it reduces the size of the 248 routing traffic instead of describing all the nodes inside it, but 249 introduces another level of hierarchy. If subnetting concept can be 250 avoided from the AS layer(with the additional overhead of computation 251 inside the SPF tree), each area can be configured from a free pool of 252 addresses based on its requirement dynamically. So, an AS can be 253 divided into number of areas of heterogeneous sizes with the nodes 254 from a free pool of address space. 256 Similarly, the concept of area can be introduced in the inter-AS- 257 bottom layer the way it works in OSPF. The area border routers in the 258 inter-AS-bottom layer have to behave exactly in the similar manner 259 the way an ABR behaves in OSPF. i.e. an area border router will hide 260 the topology inside an area to the rest of the world and will 261 distribute the collected information inside the area to the rest. It 262 will distribute the collected routing information from outside to the 263 nodes inside as well. In order to implement this, protocol running in 264 the inter-AS layer (say BGP) will have to introduce a 'cost' factor. 265 This cost factor can be interpreted as the cost of propagation of a 266 packet from one AS to another. The protocols running inside AS layer 267 (RIP/OSPF, etc) will have to the supply the cost information for a 268 packet to travel from one ASBR to another. All the protocols must 269 behave in unison for supplying this information. The cost factor is 270 needed for a remote node while sending a packet to a node inside an 271 area while more than one area border routers are equidistant from 272 that remote node. Thus inter-AS-bottom layer (i.e. one inter-AS-top 273 level node) can be divided into number of areas of heterogeneous 274 sizes with nodes of AS from a free pool of address space. BGP adopts 275 a technique called route aggregation. Along with route aggregation it 276 reduces routing information within a message. In the similar manner, 277 introduction of area inside inter-AS-bottom layer will not only 278 reduce the complexity of the protocol, but will reduce the size of a 279 BGP packet substantially. 281 With this architecture, each node(router) inside an AS is represented 282 as A.B.C. Each node may or may not be attached with a network which 283 acts as a leaf node (i.e. a network will not act as a transit). In 284 order to make use of user-id space properly and to support customer 285 networks of heterogeneous sizes, the user-ID space needs to be 286 divided as subnet-ID and user-ID. Profoundly, a VLSM (variable length 287 subnet mask) type of approach has to be adopted at each node of an 288 AS. So, each node of the AS layer will act as the root of a tree 289 whose leaves are independent small customer networks which will act 290 as stub. As the routing information of inter-AS layer as well as AS 291 layer need not be passed inside any node of the VLSM tree, each 292 router inside the tree should maintain default route for any address 293 outside of its network. With this approach, load on each router of 294 the service providers will become negligible. Protocols that supports 295 VLSM with MPLS/VPN has to be implemented inside the tree (inside the 296 VLSM tree, all the physical ports of a switch have to be configured 297 with the subnet mask. So, mere MPLS on top of static routing table 298 should do the rest). 300 The fundamental assumptions based on which this architecture lies can 301 be summarized as follows: 303 i) Entire network can be viewed as a network of regions or states 304 where each region or state can have its own identity by communicating 305 with the rest of the world through some state border routers. Each 306 region or state is a network of Autonomous Systems. Each region as 307 well as each Autonomous System inside them will have a fixed 308 (maximum) length of prefix. 310 ii) Availability of hardware resources is such that flat address 311 space can be maintained at the inter-AS layer. 313 Introduction of mesh-structured hierarchy will have several 314 advantages: 316 o Load at each router will get reduced substantially. 317 o Concept of CIDR style approach and complexity related to 318 prefix reduction can be easily avoided. 319 o Mesh structured hierarchy will make traffic evenly distributed. 320 o Physical cable connection can be optimized. 321 o Administrative issues will become easier. 323 3.2. Determination of prefix lengths 325 With this architecture, IP address can be described as A.B.C.D where 326 the D part represents the user id. Each router in the inter-AS layer 327 will have two tables of information, one for the inter-AS-top and 328 another for the inter-AS-bottom of the inter-AS-top node that it 329 belongs to. Whereas, each node of the AS layer will have three tables 330 of routing entries; one for the inter-AS-top, one for the inter-AS- 331 bottom and another for the routing information inside the Autonomous 332 System itself. In the worst case. a node inside an AS needs to 333 maintain nMaxInterASTopNodes + nMaxInterASBottomNodes + nMaxASNodes 334 entries in its routing table. 336 The dynamic nature of allocating an area from a free pool of address 337 space is more frequent at the AS layer than at the inter-AS-bottom 338 layer. As OSPF supports all the features needed, it can be considered 339 as default choice in the AS layer. Existing implementation of OSPF 340 (Version 2) supports subnetting, by which an entire area can be 341 represented as a combination of network address and subnet mask. With 342 this approach, entire routing table gets reduced substantially. With 343 the removal of subnetting, all the nodes inside an area will have an 344 entry inside the routing table (OSPF Version 1). So the deterministic 345 factor is what is the maximum number of nodes inside an AS OSPF can 346 support once subnetting support gets removed. So the prefix length of 347 AS layer will be determined by this factor of OSPF. 349 With the introduction of hierarchy in the inter-AS layer, number of 350 entries in the BGP routing table will get reduced substantially. Even 351 if pA and pB both are selected as 16, number of routing entries come 352 within the admissible range of existing BGP protocol. But, it is the 353 responsibility of IANA to come out with a scheme how 354 nMaxInterASTopNodes and nMaxInterASBottomNodes are to be selected. 355 Each top level node will have nMaxInterASBottomNodes nodes. It will 356 be a waste of address space if each country gets assigned a top level 357 nodes (e.g. china has got a population of 1,306,313,800 people where 358 as Vatican City has got only 920 according to a census of 2006). So a 359 moderate value of nMaxInterASBottomNodes is desirable, with which 360 larger countries will have a number of top level nodes. e.g. each 361 state of USA can be assigned a top level node. With the introduction 362 of area in the inter-AS-bottom layer, each top level node can be 363 divided into number of areas of heterogeneous sizes. So, a group of 364 neighboring countries with less population can share the address 365 space of a top level node. Similarly, user-id space has to be decided 366 based on the largest area VLSM tree should be spanned through. All 367 these issues are completely geo political and have to be decided by 368 IANA. 370 3.2.1. A pseudo optimal distribution of prefixes in a 64bit architecture 372 In order to have optimal use of cable connections, length of the VLSM 373 tree is expected to be as short as possible. Also any single 374 organization may prefer to have its user id space to be under the 375 same network id. So, a 16bit user-id may become insufficient for 376 places like large university campus, where as 32bit will become too 377 large. Hence, 24bit user-id will be a moderate one which is the class 378 A address space in IPv4 (also used as the space for private IP). As 379 published in 1998 [6], OSPF can support an area with 1600 routers and 380 30K external LSAs. So, 11 bits are needed to support this space. With 381 the assumption that OSPF can support much more address space with the 382 advancement of hardware technology as well as to keep the space open 383 for future expansions, 12 bits are assigned for the AS layer. 16 bits 384 are assigned for the inter-AS-bottom layer. So, if on the average, 385 16bit equivalent space gets used within the user-id space (i.e. one 386 out of 256) and 8bit equivalent nodes gets used inside an AS (16% of 387 1600), for a top level node (with 16bit equivalent AS nodes), it will 388 generate 2^40 IP addresses, which will give 8629 IP addresses per 389 person in Japan (with a population of 127417200; Japan is at the 10th 390 position from the top in the population list of the world). So, even 391 if all the countries with population less than or equal to Japan are 392 assigned a top level node and all the provinces/states of countries 393 with larger population are assigned a top level node each, total 394 number of nodes will come well under 1024. If a number of neighboring 395 countries with lesser population shares a top level node, total 396 number of top level nodes will come down further. This suggests that 397 62 bit equivalent (10(pA)+16(pB)+12(pC)+24(user-id)) space will be 398 good enough for unicast addresses. This distribution expects OSPF to 399 support 65K (64K+1K) external LSAs. 401 64bit address space may be divided into two 63bit blocks as follows: 403 i. Global unicast addresses with the most significant bit set to 0. 404 This space is equally divided into provider assigned (PA) address 405 space with prefix 00 and provider independent (PI) address space with 406 prefix 01. Provider independent address space will be used for the 407 customers who would like to retain their number even after changing 408 their providers. As routing will be based on PA addresses, each PI 409 address will be associated to at least one PA address. Section 4 410 describes issues related to PI addressing in detail. 412 ii. Address space with the MSB set to 1 will be distributed within 413 the rest. Each of them will have a fixed prefix which will be 414 determined with the consultation with IANA. This distribution will 415 be based on the requirements and the work that have already been done 416 in connection to IPv6 along with the following requirements: 418 a) Router address space: Any node in the router address space will be 419 designated with a prefix followed by A.B.C.router-id. 421 b) Address space for multicasting: 423 c) Address space for private IP: A 32 bit address space should be 424 good enough for private IP. 426 3.2.2. Whether to go for a two-tier or three-tier hierarchy 428 Establishment of hierarchy in the inter-AS layer reduces the size of 429 BGP entries to a great extent, but leads to an improper use of 430 address space due to geo-political reason. If hierarchy in the inter- 431 AS space gets removed, entire 26bit (10+16) space will be available 432 for a single layer and use of inter-AS space will be true to its 433 sense, but will increase external LSA (and/or number of entries in 434 the BGP table) dramatically. So, it depends on to what extent OSPF 435 can support external LSAs. BGP expects the packet length to be 436 limited to 4096 bytes. BGP manages to make it work with this 437 limitation with the concept of prefix reduction in the CIDR based 438 environment. As the number of inter-AS nodes increases, BGP has to 439 change this limit in order to make it work in flat address space. The 440 alternate will be to divide the inter-AS space into number of areas 441 as defined in section 2.1. The area border routers will advertise the 442 aggregated information to the rest of the world. BGP may have to 443 incorporate both the options at the same time. As the number of 444 nodes in the inter-AS layer increases, in order to reduce the number 445 of entries in the routing table, inter-AS space has to be split into 446 two separate planes. So, two-tier hierarchy can be considered as an 447 interim state to go for three-tier hierarchy. If it so happen that 448 current available data is good enough to support the present need, it 449 will be worth to look for to what extent it can support in the 450 future. Assignment of inter-AS nodes in two-tier hierarchy should be 451 based on the geographical distribution as if it is part of three-tier 452 hierarchy. Otherwise, introduction of three-tier hierarchy in the 453 future will become another difficult task to go through. Based on the 454 report of year 2011, BGP supports ~400,000 entries in the routing 455 table. With this growing trend, BGP may have to change the limit of 456 packet length even in a CIDR based environment. With the introduction 457 of two-tier hierarchy, number of entries in the routing table will 458 come down drastically and with the three-tier approach, it will come 459 down further. 461 3.3. Issues related to Satellite communications 463 Establishment of hierarchy in the inter-AS layer expects the only way 464 any two autonomous systems in two different top level nodes 465 communicate is through their SBRs. If two autonomous systems inside 466 the same top level node communicate through satellite, it will be 467 considered as a direct link between them. Whenever autonomous system 468 'ASa' of top level node 'A' communicates with autonomous system 'ASb' 469 of top level node 'B' through satellite, they have to go through 470 their state border routers. i.e. satellite port inside 'A' that 471 communicates with a satellite port inside 'B' will be considered as 472 state border router. If multiple such ports exists inside node 'A', 473 all of them will be equidistant from any port inside 'B'. Which 474 expects any satellite port inside 'B' to have prior knowledge of list 475 of autonomous systems that will be under the purview of any port 476 inside 'A'. So, all the satellite ports of 'A' have to exchange such 477 group of information with all the satellite ports of 'B' and vice 478 versa. These group of autonomous systems can be considered as a 479 cluster of autonomous systems inside an area of a top level node. If 480 number of such ports is small, some heuristics can be applied while 481 assigning AS numbers in order to reduce the processing time during 482 the circuit establishment phase. It will become difficult to 483 maintain such heuristics once the number of such ports becomes large. 484 So, in case of satellite communication, the advantage of establishing 485 hierarchy inside inter-AS layer diminishes as the number of satellite 486 ports increases. If any private corporate maintains its own satellite 487 channel to communicate between its offices at distant locations, all 488 of these offices are going to be considered as under the user-id 489 space of its network. Service providers that provide satellite 490 services to the end-site customers, can operate in the usual manner 491 as they will provide connection to customer networks which will act 492 as stub. 494 4. Provider Independent addressing, name services and multihoming 496 Provider independent addressing can be conceived as naming a host 497 with a number. It can be used by customer networks who would like to 498 retain their number even after changing their service provider; also 499 it is useful to designate a host uniquely if the customer network is 500 multihomed. Just like in name services, as address corresponding to a 501 name needs to be resolved first to initiate communication, the same 502 is required for PI addressing. Each globally unique PI address will 503 be associated to at least one global unicast provider assigned 504 address. For a host with single interface, this number will be same 505 as the number of service providers the customer network is associated 506 with. 508 As either source or destination or both may be multihomed, there 509 could be multiple paths to communicate between two hosts. This is 510 required both for name services as well as for PI addressing. 512 A system call needs to be introduced to get the source address based 513 on the destination address. If application program needs to use the 514 destination address directly, it needs to use this system call. 516 int getcommaddr(int sockfd, struct in_addr *dst, struct addr_pair 517 *endpts); 519 'addr_pair' holds the addresses of communication end points as 520 follows: 522 struct addr_pair { 523 struct in_addr src; 524 struct in_addr dst; 525 }; 527 'getcommaddr'[8] returns the number of source-destination pairs for 528 communication; the field 'endpt' will hold the array of these 529 addresses. The array will be in sorted manner based on the best 530 possible route. 'sockfd' is used to get the 'type of service' 531 assigned. So, an application program needs to set its type of service 532 before using this call. 534 'getcommaddr needs to call a routine 'getmappedaddr' to resolve the 535 mapped provider assigned addresses of a provider independent address. 537 int getmappedaddr(struct in_addr *piaddr, struct in_addr *mpiaddr); 539 'getmappedaddr' will return number of mapped addresses and 'mpiaddr' 540 will hold their values. 542 Users may use name instead of IP address to reach the destination. A 543 new system call needs to be introduced 'gethostbynamewithsrcaddr', 544 which is an extension to 'gethostbyname' as follows: 546 struct hostent *gethostbynamewithsrcaddr(int sockfd,const char *name, 547 int *nroutes, struct addr_pair *endpts); 549 'gethostbynamewithsrcaddr'[8] takes 'name' and 'sockfd' as input 550 parameters and finds out the best possible route to reach the 551 destination. It returns the pointer to the 'hostent' structure as 552 returned by 'gethostbyname' system call. The parameter 'nroutes' 553 gets the number of possible routes to be used and the corresponding 554 source and destination addresses gets assigned to 'endpts' in sorted 555 manner. 'sockfd' is used to get the 'type of service' assigned. So, 556 an application program needs to set its type of service before using 557 this call. 559 An application program needs to use these source addresses from the 560 top (i.e. the 0th) to establish connection with the destination. It 561 needs to bind source address 'src' and then connect with the 562 destination address 'dst'. 564 4.1. PI address Resolution 566 There could be several approaches to resolve mapped addresses for a 567 PI address. This section tries to come up with a solution with the 568 approach of DNS[7] with necessary differences. Just like name space 569 in DNS, entire address range with prefix 01 will be the address space 570 used by PI addresses. Servers that will hold the information of 571 mapping between PI addresses and corresponding PA addresses will be 572 called as PIMapServers and the programs that will be used to resolve 573 addresses will be called as PIMapResolvers. 575 In case of DNS where name is used in hierarchical format to resolve 576 the addresses, PI address resolution will be based on the prefix of 577 the PI address used for resolution. The prefix is dependent on the 578 architectural model used for the internet and there can be several 579 approaches for prefix determination. Based on the prefix information 580 addresses of a list of servers can be found out that will act as root 581 servers which will be used to resolve mapped PA addresses 582 corresponding to that PI address. A prefix will serve a fixed address 583 space within entire PI address space. Address space belonging to a 584 prefix will be distributed within customer networks of heterogeneous 585 sizes. Address space allocation and the mapping of associated PA 586 address(es) will be assigned by a regional authority. The regional 587 authority will be fully responsible for the operation of root servers 588 in that region. 590 In "Mesh Structured Hierarchy" every global PA address is represented 591 as "00.A.B.C.user-id". In order to support customer networks of 592 heterogeneous sizes with the approach of VLSM, the "user-id" portion 593 is further divided as "subnet-id.userid". So, the effective network 594 prefix of a customer network in PA address space is "00.A.B.C.pa- 595 subnet-id". Within an "A.B", entire PI address space with prefix 596 "01.A.B" will be distributed within customer networks of 597 heterogeneous sizes. So, effective network prefix of a customer 598 network with PI address will be "01.A.B.pi-subnet-id". A particular 599 prefix "01.A.B.pi-subnet-id" will be mapped to at least one provider 600 assigned prefix of same prefix length. For a multihomed customer 601 network within "A.B" that receives services from two service 602 providers will have prefixes "00.A.B.C1.pa-subnet-id1" and 603 "00.A.B.C2.pa-subnet-id2". A PI address prefix "01.A.B.pi-subnet-id" 604 of same length will be mapped to both these prefixes of PA address 605 space. Every region "A.B" will have maximum four root servers of net 606 addresses "00.A.B.server1", "00.A.B.server2", "00.A.B.server3" and 607 "00.A.B.server4". Absolute values of these server ids will be 608 assigned by IANA. 610 Each PIMapServer will have a database of records that will have 611 information to resolve PI addresses. Each record will have the 612 following format. 614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 | Net Address | Net Mask | Type | Addr1 | Addr2 | Addr3 | Addr4 | 616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 First two fields "NetAddress/NetMask" represents the PI address range 619 of a network. "Type" will be either Direct/Referral/Individual based 620 on which a query and rest of the fields of a record have to be 621 processed. A PI address can have maximum four mapped PA addresses. 622 "Addr1", "Addr2", "Addr3", "Addr4" will hold the corresponding PA 623 addresses. When a server receives a query for an address "X", it 624 extracts the record of the network based on "NetAddress/NetMask" and 625 "X" from its database. If no matching record is found, a negative 626 response is sent. Based on the "Type" of the record, the query is 627 processed in the following manner. 629 Type=Direct: 631 This is the most common type. If a customer network would not like to 632 maintain a map server opts for this option. In this case there will 633 be one to one mapping between a PI address and corresponding PA 634 addresses. The fields "Addr1"/"Addr2"/"Addr3"/"Addr4" will hold the 635 PA Net Addresses corresponding to the PI address of the network. 636 Server will extract the user-id portion of "X" and find the 637 corresponding mapped PA addresses based on "Addr1"/"Addr2"/...etc. 639 Theoretically, "A.B" portion of a PI address need not match with the 640 "A.B" portion of the corresponding PA addresses. Consider a large 641 corporate that has its corporate office and a branch office within 642 the same region of a particular "A.B" and some other offices with 643 different values of "A.B". The corporate can maintain a contiguous 644 range of PI addresses for the ease of its operation. It needs to 645 split entire PI address range based on its offices and assign the 646 corresponding PA addresses. In order to minimize the path of a query 647 it is desirable that "A.B" of a PI address and its corresponding 648 mapped PA addresses belong to the same region. 650 Type=Referral: 652 When a customer network would like to have a direct control for the 653 mapping of its addresses it needs to opt for this option. 654 "Addr1"/"Addr2"/"Addr3"/"Addr4" of the database entry will hold the 655 PA addresses of the map servers that need to be queried for further 656 processing. A server may act either in recursive mode or in iterative 657 mode based on its implementation just like in DNS. A large corporate 658 may have different offices and each (or some of them) may maintain a 659 map server based on their policies. 661 When a server needs to handle a particular address separately, it 662 needs to set "Net Address" with that particular address and all the 663 bits of "Net Mask" will be set to "1". If some of its addresses need 664 to be handled separately but for the rest common rule may apply (like 665 Type=Direct), records of the individual entries should be processed 666 first and then for the rest. So, individual entries needs to be 667 entered first and then the common cases into the database. In this 668 case the database has to be processed sequentially from the top. 670 For a host having multiple interfaces, each interface may be assigned 671 a PA address supplied by the same service provider, but it is 672 desirable that PI address gets mapped to only one of them (preferably 673 the interface which will have the shortest path from the associated 674 CE router). 676 Type=Individual: 678 This is meant for the individual users opting for services like 679 telephonic services that need to maintain PI address. With this 680 option a mobile user may maintain its PI address after changing its 681 service provider. A map server needs to maintain some networks with a 682 range of PI addresses in its database. When a query for an address 683 "X" is received, server needs to get the corresponding record which 684 will point to a separate database where there will be one to one 685 mapping between PI address and its corresponding PA address of all 686 the assigned PI addresses. These networks and assignment of 687 individual PI addresses have to be done by the regional authority. 689 Messages will be of type (octet) "Query=1" or "Answer=2". Each 690 message will have a message type followed by an ID (short int). This 691 ID will be generated by the resolver and the answer of the query will 692 be returned with the same ID. Answer will be in the form of PA 693 address or Referral PA Address. The field "Data Type"(octet) will 694 hold the corresponding value. 696 Message with type "Query" will have the following fields: 698 Message Type(01)+ID+PI address. 700 Message with type "Answer" will have the following fields: 702 Message Type(02)+ID+PI address+Data Type+Number of 703 Addresses(octet)+PA addresses; 705 Date Type=PA Address(01)/Referral PA Address(02) 707 If no mapping address is found, "Data Type" will be set to "PA 708 Address" and "Number of Addresses" will be set to 0. 710 5. Issues related to IP mobility 712 An interface of a customer network may have several IP addresses 713 (e.g. for a multihomed customer site, each interface will have 714 multiple global unicast addresses also it may have private 715 addresses). For a mobile node that has been moved to a customer 716 network which gets service from a service provider and maintains 717 private IP addresses, will have at least three IP addresses; provider 718 assigned unicast address, private address and its permanent "Home 719 Address". The "Home Address" will be aliased with the provider 720 assigned address (i.e. the co-located care-of address). So the 721 interface structure needs to have an additional field to hold the 722 value of care-of address. The PCB structure will have an additional 723 field 'inp_lcladdr'. So 'inp_lcladdr' will have the current provider 724 assigned address that a foreign node needs to use for communication. 725 The field 'inp_laddr' that is used to hold the value of local address 726 will hold the value of "Home Address" of a mobile node. Similarly, 727 PCB needs to introduce another field 'inp_fcladdr' to support the 728 destination address to be mobile. The existing field 'inp_faddr' 729 which is used to address a foreign address will hold the value of 730 "Home Address" of the mobile node. Customers with PI address who 731 would like to have mobility support, the mapped address will be 732 considered as the "Home Address" of the mobile node. 734 An outgoing packet from a mobile node in a foreign site needs to be 735 stacked with the associated care-of address. While initiating 736 communication, the 'bind' system call needs to go through the 737 interface list and fetch the associated structure to check whether 738 the source address is aliased or not and needs to fill the value of 739 'inp_lcladdr' of PCB accordingly. 741 When TCP receives a SYN for connection establishment, it allocates a 742 PCB and assigns the values for 'inp_laddr', and related fields. 743 During this phase, TCP also needs to check whether the local address 744 is aliased or not (based on the fields of interface structure; which 745 is applicable for a mobile node at foreign site) and needs to fill 746 the values of 'inp_lcladdr' accordingly. Similarly if destination 747 address is found to be aliased, based on the stacking type, it needs 748 to fill up the field 'inp_fcladdr'. 750 IP address stacking can be performed with the approach introduced in 751 section 6.4 of RFC6275[9]. RFC6275 talks about the stacking of IP 752 addresses for a destination address (Let us call it as type 0 753 stacking). Two more types of stacking need to be introduced; type 1 754 stacking where only source address will appear in the stack and type 755 2 stacking where both source address and destination address will 756 appear in the stack with a particular type of ordering. 758 Protocol output routine like 'tcp_output' or 'udp_output' needs to 759 fill the IP packet in the following manner. 761 If the socket contains a valid 'inp_lcladdr', use 'inp_lcladdr' as 762 the source address and 'inp_laddr' will appear in the stack. If the 763 socket contains a valid 'inp_fcladdr' use 'inp_fcladdr' as the 764 destination address and 'inp_faddr' will appear in the stack. If only 765 'inp_fcladdr' contains a valid address where as 'inp_lcladdr' is 766 NULL, use type 0 stacking. If only 'inp_lcladdr' contains a valid 767 address where as 'inp_fcladdr' is set as NULL, use type 1 stacking. 769 If both 'inp_lcladdr' and 'inp_fcladdr' contains valid addresses, use 770 type 2 stacking. 772 Protocol input routine like 'tcp_input' or 'udp_input' needs to 773 process the packet in the reverse order based on the type of 774 stacking. For type 0 stacking, use the address in the stack as the 775 destination address; for type 1 stacking, use the address in the 776 stack as the source address; for type 2 stacking use both source 777 address and destination address from the stack. 779 5.1. Changes expected with the specifications related to IP mobility 781 RFC6275 demands correspondent node binding from mobile nodes for 782 route optimization. This binding is required when a connection gets 783 established as well as when the mobile node changes it address space. 784 There are application like HTTP which opens up multiple connections 785 on the run time which are very short lived. If mobile nodes need to 786 send binding messages for all the connections, network will be 787 unnecessarily congested. This congestion can be avoided with the 788 establishment of binding at the time of connection establishment 789 itself. So, if TCP server happens to be mobile, it will set the 790 value of 'inp_lcladdr' in the stack while sending SYN+ACK. TCP client 791 which initiates communication through 'connect' needs to set 792 'inp_fcladdr' field on receiving TCP+ACK. With this approach 793 correspondent node binding messages need to be sent only when a 794 mobile node changes its position from one address space to another. 796 Route optimization is not applicable to applications which are of 797 multicast type. In these cases packets need to be forwarded with the 798 mechanism of reverse tunneling with the approach of "IP Encapsulation 799 within IP" as defined in RFC 2003. In order to support packet 800 delivery with route optimization method as well as with 801 "Encapsulating Delivery Style" based on the application type the 802 protocol control block needs to introduce another field 803 'inp_hagentaddr' to hold the address of the home agent of the mobile 804 node. The interface structure also needs to have same field. The 805 'bind' system call needs to go through the interface list to fetch 806 'inp_hagentaddr' to the PCB along with 'inp_lcladdr' as described 807 earlier. So, protocol output routines like 'tcp_output', 'udp_output' 808 need to fill up the packets based on the application type. In 809 "Encapsulating Delivery Style" packets need to be formed in the 810 following manner. 812 The inner IP header will contain 813 Source Address: Home address of the mobile node 814 (i.e. 'inp_laddr') 815 Destination address: Address of the correspondent node 816 (i.e. 'inp_faddr') 818 The outer IP header will contain 819 Source Address: co-located care of address of the mobile node 820 (i.e. 'inp_lcladdr') 821 Destination Address: Address of the home agent of the mobile node 822 (i.e. 'inp_hagentaddr') 823 Protocol field: IP in IP 825 6. Refinements over existing IPv6 specification 827 As IPv6 was envisioned long before some of the newer technologies 828 e.g. MPLS came into picture, some refinements can be made over the 829 existing specification. These considerations are related to bandwidth 830 usages and performance inside switches. Experimental results show 831 that smaller packet size gives better result for the processing of RT 832 packets. So, it is desirable to have IP packet header to be as small 833 as possible. 835 As described earlier, evaluation of the parameters 836 nMaxInterASTopNodes, nMaxInterASBottomNodes and nMaxASNodes is geo- 837 political and have to be decided by IANA. Once these parameters are 838 determined with mutual agreements, values of pA, pB, pC and prefix 839 length of user id can be determined. With 64bit address space, IP 840 header will be reduced by 16 bytes. 842 The 'flow label' field of IPv6 packet header may not be of any use 843 with MPLS is in use. ATM used to have 4 priority classes. The first 844 specification of IPv6 RFC-1883 used a 4bit type of service field 845 along with a 24bits flow label field. These two were modified to a 846 8bit type of service field and a 20bit flow label field in the 847 current spec RFC-2460. Too many priority classes may increase 848 complexities to process inside switches. If type of service field of 849 IPv6 header may be reduced to be of 4bit length as it was stated in 850 RFC-1883 and 'flow label' field gets removed, another three bytes may 851 be reduced from the IPv6 header. 853 The field 'Hop Limit' has got a 8bit value in the existing spec. The 854 role of this field needs to be discussed properly with a large 855 address space. 857 RFC4862[10] introduces the concept of "Stateless auto configuration" 858 with the goal in mind that no manual configuration is required by 859 individual machines before connecting them to the network. It 860 generates a link local address with a link-local prefix and the link 861 address (e.g. Ethernet/E.164 for ISDN) first. This link local address 862 is used to configure global unicast address and any other 863 configurable parameters based on router advertisement. Global 864 unicast addresses are generated by the prefix supplied by the router 865 advertisement and the link specific interface identifier. This 866 identifier can be as large as 64 bit length. So irrespective of the 867 size of the network (it may be 10000 or 100 or even less than that) 868 every customer network will consume a 64bit equivalent addresses. 869 This seems to be a huge blunder. What is expected is the length of 870 the interface identifier is equivalent to support the number of nodes 871 supported by that subnet. In order to achieve this the router itself 872 or a server in that subnet needs to maintain a storage which will 873 generate the interface identifier based on the request from 874 individual hosts. It may be desirable that interface identifiers are 875 generated from DHCP servers. With the option of generating interface 876 identifier through DHCP, changes in the auto configuration process 877 can be looked at as follows: 879 From the point of view of a host, it can be considered as a two step 880 process. Host needs to send Router Solicitations message to find out 881 the presence of a router. Router Advertisement message should include 882 an option field which will inform whether prefix information should 883 be configured through Router Advertisement or through DHCP. Host 884 needs to send a request message to get the interface identifier. If 885 both the information needs to be obtained from a DHCP server they can 886 be obtained through a single message. 888 From the server's point of view, it needs to maintain a database for 889 a mapping of the link-layer address and subnet specific interface 890 identifier. Lifetime of an interface identifier has to be processed 891 in the usual manner the way existing DHCP implementation treats IP 892 addresses. 894 There seem to be another possible danger to obtain prefix information 895 through Router Advertisement. As the Router Advertisement comes in 896 the form of ICMP messages, once it is received by the ICMP layer, it 897 looses information from which interface the message has been received 898 (This problem arises for hosts that are having multiple interfaces 899 and not all of them are attached to the same subnet). So, auto 900 configuration of a host has to be performed one interface at a time 901 by making all other interfaces disabled. Once configuration of all 902 the interfaces are done, all of them have to be enabled. 904 If it is expected that hosts should reconfigure their addresses 905 dynamically based on Router Advertisement message, Router 906 Advertisement needs to generate a special message for a certain 907 amount of time that needs to include old prefix and the corresponding 908 new prefix in the message. 910 In order to support multihoming[8], prefix information needs to 911 include the fields 'default router' and 'next hop address' to reach 912 the default router for each of the prefixes. 914 In a 64bit architecture, link-local address can be formed with a 915 link-local prefix and link-layer address in a suitable manner; say it 916 can be formed with a 16bit link-local prefix followed by a 48bit 917 link-layer address. For hardware that supports more than 48bit 918 addressing (say E.164), the least significant 48bits may be 919 considered to generate link-local addresses. 921 7. Distributed processing and Multicasting 923 With the inherent hierarchy involved in this architecture, 924 distributed applications can also be structured in a suitable manner. 925 Say, for a commonly used web based application a master level server 926 will be there at every top level node. Any change that might happen 927 in the application, has to be synchronized within these master level 928 servers first. There might be servers at the middle layer (inside 929 each inter-AS-bottom) inside each top level node. Once the changes 930 get reflected at the master node, all the servers at the middle layer 931 needs to update themselves with their master level node. This will 932 reduce network traffic substantially. Inherent hierarchy in the 933 architecture will also help establishing multicast tree in the 934 similar manner. Work on these issues can be progressed only after 935 this architecture gets approved. 937 8. Transition to real IP from private IP 939 Both CIDR based hierarchy and Mesh structured hierarchy expects a 940 VLSM tree at the bottom. In VLSM, in real IP space with provider 941 assigned (PA) addresses, assignment of network resources has to be 942 associated with the address space to be used with the type of 943 service. Within a typical switch supporting multiple types of ports, 944 a line card of strength OC48 can be replaced with 4 line cards of 945 strength OC12. An OC12 card may also be replaced with 4 OC3 cards. An 946 OC12 card may be attached to another switch with DS3 ports and so on. 947 When it reaches to the customer network port density of a switch has 948 to be directly proportional to the address block that a customer 949 network will be assigned to. i.e. each customer network has to be 950 assigned a block of address space (say, 128, 256, 512, 1K, 2K etc). 951 Within the switch these ports have to be assigned net address/net 952 mask the way VLSM works. 954 In IPv4 environment, providers have provided services in terms of 955 bandwidth of the ports say, 2 Mbps/4 Mbps/1 Gbps line etc. If these 956 ports were assigned addresses based on the number of users of the 957 customer network, transition from private IP to real IP is simple. 958 Consider a switch that has supplied 2 Mbps line to a set of customers 959 with number of users within 1K to 2k, each of them will be assigned a 960 block of 2K each. But if number of users are not proportional to the 961 bandwidth used, say same 2 Mbps line were used to customers of sizes 962 1K, 2K 10K and 16K respectively reorganization will be needed if 963 possible. This rearrangement may be possible within the switch itself 964 or by connecting ports of appropriate sizes from different switch, 965 otherwise each of them has to be assigned an address block of 16K 966 each or with the way VLSM works whatever is suitable. So, address 967 block assignment in the VLSM tree has to grow in a bottom up 968 approach. 970 Thus, transition of existing provider network without (or very 971 little) rearrangement to a real IP space with CIDR based approach is 972 apparently not a difficult job. In a CIDR based approach, sizes of 973 the VLSM trees are heterogeneous that leads to number of routing 974 entries to be very high. Mesh structured hierarchy is convenient to 975 reduce the routing overhead as well as for distribution of network 976 resources in a suitable manner in the long run. To covert CIDR based 977 approach to Mesh structured hierarchy requires reorganization mainly 978 in the routing domain and by splitting trees of very large sizes (>24 979 bit address space) at the top. 981 Section 3.2.1 reveals that in Mesh structured hierarchy a 64bit 982 architecture will be good enough for our need in a provider assigned 983 (PA) address space; the same is true for CIDR based approach as well. 985 9. IANA Consideration 987 This is a first level draft for proposed standard. Hence, IANA 988 actions should come into play at a later stage, if needed. 990 10. Security Consideration 992 This document does not include any security related issues. 994 11. Acknowledgments 996 The author would like to thank to Professor Amitava Datta of 997 University of Western Australia for his review and constructive 998 comments. 1000 12. Normative References 1002 [1] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for 1003 IPv6 Hosts and Routers", RFC 4213, October 2005. 1005 [2] Fuller V., Li. T., "Classless Inter-Domain Routing (CIDR): The 1006 Internet Address Assignment and Aggregation Plan", RFC 4632, 1007 August 2006. 1009 [3] Huston, G., "Commentary on Inter-Domain Routing in the 1010 Internet", RFC 3221, December 2001. 1012 [4] Q. Vohra, E. Chen., "BGP Support for Four-octet AS Number 1013 Space", RFC 4893, May 2007. 1015 [5] Srisuresh, P. and K. Egevang, "Traditional IP Network Address 1016 Translator (Traditional NAT)", RFC 3022, January 2001. 1018 [6] J. Moy., "OSPF Standardization Report", RFC 2329, April 1998 1020 [7] P.V. Mockapetris., "Domain names - concepts and facilities", 1021 RFC 1034, November 1987. 1023 [8] S. Bandyopadhyay, "Solution for Site Multihoming in a Real IP 1024 Environment", work in progress. 1026 [9] C. Perkins, Ed., D. Johnson, J. Arkko, "Mobility Support in 1027 IPv6" RFC 6275, July 2011. 1029 [10] S. Thomson, T. Narten, T. Jinmei, "IPv6 Stateless Address 1030 Autoconfiguration", RFC 4862, September 2007. 1032 13. Informative References 1034 [11] Postel, J., "Internet Protocol", STD 5, RFC 791, 1035 September 1981. 1037 [12] Rekhter, Y., and T., Li, "A Border Gateway Protocol 4 (BGP- 1038 4)",RFC 1771, March 1995. 1040 [13] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 1041 Specification, RFC 1883, December 1995. 1043 [14] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 1045 [15] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 1046 Specification", RFC 2460, December 1998. 1048 [16] Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol 1049 Label Switching Architecture", RFC 3031, January 2001. 1051 14. Author's Address 1053 Shyamaprasad Bandyopadhyay 1054 HL No 205/157/7, Kharagpur 721305, India 1055 Phone: +91 3222 225137 1056 e-mail: shyamb66@gmail.com