1. Trang chủ
  2. » Công Nghệ Thông Tin

The network layer Addressing and routing

15 654 1
Tài liệu đã được kiểm tra trùng lặp

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

THÔNG TIN TÀI LIỆU

Thông tin cơ bản

Định dạng
Số trang 15
Dung lượng 276,8 KB

Nội dung

The network layer Addressing and routing

The network layer Addressing and routing Mobility and addressing What is the DHCP protocol used for? Assign IP addresses and network conguration of automatic way What are the advantages of DHCP in comparison with a manual configuration? Disadvantages of manual conguration: (A) it is possible to assign an IP address has two different stations, (B) to err in the conguration (subnet mask, network, default gateway) (C) generates a high administrative burden in case of "nomadic" users Benefits of DHCP server provides all the information conguration TCP / IP with the customer The user no longer needs to visit his administrator for information on its conguration What is the difference between DHCP and the BOOTP or RARP protocols? DHCP is based on BOOTP and maintains some backward compatibility The main difference is that BOOTP was designed for manual pre-conguration of the host information in a server database, while DHCP allows for dynamic allocation of network addresses and congurations to newly attached hosts Additionally, DHCP allows for recovery and reallocation of network addresses through a leasing mechanism RARP is a protocol used by Sun and other vendors that allows a computer to find out its own IP number, which is one of the protocol parameters typically passed to the client system by DHCP or BOOTP RARP doesn’t support other parameters and using it, a server can only serve a single LAN DHCP and BOOTP are designed so they can be routed What is the Client ID used for? What is termed the Client ID for the purposes of the DHCP protocol is whatever is used by the protocol to identify the client computer By default, DHCP implementations typically employ the client’s MAC address for this purpose, but the DHCP protocol allows other options Some DHCP implementations have a setup option to specify the client ID you want One alternative to the MAC address is simply a character string of your choice In any case, in order for DHCP to function, you must be certain that no other client is using the client ID you choose, and you must be sure the DHCP server will accept it What are the four phases necessary so that a customer DHCP obtains a configuration of a DHCP server? (A) Dissemination of IP lease request (B) Dissemination of a proposed lease IP server in response to the request (C) The customer selects a lease that suits him (Sending a message to request a rental lease) (D) The server responds originally meant the proposal and other DHCP servers withdraw their proposal Can a DHCP server be used as backup for another DHCP server? You can have two or more servers handing out leases for different addresses If each has a dynamic pool accessible to the same clients, then even if one server is down, one of those clients can lease an address from the other server However, without communication between the two servers to share their information on current leases, when one server is down, any client with a lease from it will not be able to renew their lease with the other server Such communication is the purpose of the "server to server protocol" (see next question) It is possible that some server vendors have addressed this issue with their own proprietary server-to-server communication Does that have a direction to think that a computer which was already seen allocating an address by DHCP in request another temporarily to this same server? There is nothing in the protocol to keep a client that already has a leased or permanent IP number from getting a(nother) lease on a temporary basis on another subnet (i.e., for that laptop which is almost always in one oce, but occasionally is plugged in in a conference room or class room) Thus it is left to the server implementation to support such a feature I’ve heard that Microsoft’s NT-based server can it How to choose the lease length of an address? Define the standard which appear important to you I’ve asked sites about this and have heard answers ranging from 15 minutes to a year Most administrators will say it depends upon your goals, your site’s usage patterns, and service arrangements for your DHCP server A very relevant factor is that the client starts trying to renew the lease when it is halfway through : thus, for example, with a day lease, the client which has lost access to its DHCP server has days from when it rst tries to renew the lease until the lease expires and the client must stop using the network During a 2-day outage, new users cannot get new leases, but no lease will expire for any computer turned on at the time that the outage commences Another factor is that the longer the lease the longer time it takes for client conguration changes controlled by DHCP to propogate Some relevant questions in deciding on a lease time : Do you have more users than addresses ? If so, you want to keep the lease time short so people don’t end up sitting on leases Naturally, there are degrees In this situation, I’ve heard examples cited of 15 minutes, hours, and days Naturally, if you know you will have 20 users using 10 addresses in within a day, a day lease is not practical Are you supporting mobile users ? If so, you may be in the situation of having more users than addresses on some particular IP number range See above Do you have a typical or minimum amount of time that you are trying to support ? If your typical user is on for an hour at minimum, that suggest a hour lease at minimum How many clients you have and how fast are the communications lines over which the DHCP packets will be run ? The shorter the lease, the higher the server and network load In general, a lease of at least hours is long enough that the load of even thousands of clients is negligible For shorter leases, there may be a point beyond which you will want to watch the load Note that if you have a communication line down for a long enough time for the leases to expire, you might see an unusually high load it returns If the lease-time is at least double the communication line outage, this is avoided How long would it take to bring back up the DHCP server, and to what extent can your users live without it ? If the lease time is at least double the server outage, then running clients who already have leases will not lose them If you have a good idea of your longest likely server outage, you can avoid such problems For example, if your server-coverage is likely to recover the server within three hours at any time that clients are using their addresses, then a six hour lease will handle such an outage If you might have a server go down on Friday right after work and may need all Monday’s work-day to x it, then your maximum outage time is days and a 6-day lease will handle it Do you have users who want to tell other users about their IP number ? If your users are setting up their own web servers and telling people how to get to them either by telling people the IP number or through a permanent DNS entry, then they are looking for an IP number that won’t be changing While some sites would manually allocate any address that people expected to remain stable, other sites want to use DHCP’s ability to automate distribution of relatively permanent addresses The relevant time is the maximum amount of time that you wish to allow the user to keep their machine turned o yet keep their address For example, in a university, if students might have their computers turned o for as long as three weeks between semesters, and you wish them to keep their IP address, then a lease of six weeks or longer would suffice Some examples of lease-times that sites have used and their rationals : 15 minutes : To keep the maximum number of addresses free for distribution in cases where there will be more users than addresses hours : Long enough to allow the DHCP server to be xed, e.g hours 12 hours : If you need to take back an address, then you know that it will only take one night for the users’ lease to expire days : This is apparently Microsoft’s default, thus many sites use it days :Long enough that a weekend server outage that gets xed on Monday will not result in leases terminating months : Long enough that students can keep their IP address over the summer hiatus I believe this rational is workable if the summer hiatus is no more than months One year : If a user has not used their address in six months, then they are likely to be gone Allows administrator to recover those addresses after someone has moved on Can the server control if the allocated addresses are always used by the clients? There is no ideal answer : you have to give something up or some extra work You can put all your clients on a subnet of your own along with your own DHCP server You can use manual allocation Perhaps you can nd DHCP server software that allows you to list which MAC addresses the server will accept DHCP servers that support roaming machines may be adapted to such use You can use the user class option assuming your clients and server support it : it will require you to congure each of your clients with a user class name You still depend upon the other clients to respect your wishes 10 Can a DHCP server prohibit machines not to allocate itself an IP address that it manages? This would have to be done using a mechanism other than DHCP DHCP does not prevent other clients from using the addresses it is set to hand out nor can it distinguish between a computer’s permanent MAC address and one set by the computer’s user DHCP can impose no restrictions on what IP address can use a particular port nor control the IP address used by any client 11 Explain what would be the problem if an intruder on a network has taken a place mischievously in a DHCP server? A malicious user could make trouble by putting up an unocial DHCP server The immediate problem would be a server passing out numbers already belonging to some computer yielding the potential for two or more "innocent bystander" nodes ending up with the same IP number Net result is problems using the nodes, possibly intermittent of one or the other is sometimes turned o A lot of problems are possible if a renegade server manages to get a client to accept its lease oering, and feeds the client its own version of other booting parameters One scenario is a client that loads its OS over the network via tftp being directed to a different le (possibly on a different server), thus allowing the perpetrator to take over the client Given that boot parameters are often made to control many different things about the computers’ operation and communication, many other scenarios are just as serious Note that BOOTP has the same vulnerabilities The "broadcast ag" : DHCP includes a way in which client implementations unable to receive a packet with a specic IP address can ask the server or relay agent to use the broadcast IP address in the replies (a "ag" set by the client in the requests) The denition of DHCP states that implementations "should" honor this ag, but it doesn’t say they "must" Some Microsoft TCP/IP implementations used this ag, which meant in practical terms, relay agents and servers had to implement it A number of BOOTP-relay-agent implementations (e.g in routers) handled DHCP just ne except for the need for this feature, thus they announced new versions stated to handle DHCP Some of the virtual LAN schemes, i.e., those that use the packet’s IP number to decide which "virtual LAN" a client-computer is on for the purposes of TCP/IP, don’t work when using DHCP to dynamically assign addresses DHCP servers and relay agents use their knowledge of what LAN the client-station is on to select the subnet number for the client-station’s new IP address whereas such switches use the subnet number sent by the client-station to decide which (virtual) LAN to put the station on Routers are sometimes congured so that one LAN on one port has multiple network (or subnet) numbers When the router is relaying requests from such a LAN to the DHCP server, it must pass along as IP number that is associated with one of the network (or subnet) numbers The only way the DHCP server can allocate addresses on one of the LAN’s other network (or subnet) numbers is if the DHCP server is specically written to have a feature to handle such cases, and it has a conguration describing the situation The knowledge that a particular IP number is associated with a particular node is often used for various functions Examples are : for security purposes, for network management, and even for identifying resources Furthermore, if the DNS’s names are going to identify IP numbers, the numbers, the IP numbers have to be stable Dynamic conguration of the IP numbers undercuts such methods For this reason, some sites try to keep the continued use of dynamically allocatable IP numbers to a minimum With two or more servers serving a LAN, clients that are moved around (e.g mobile clients) can end up with redundant leases Consider a home site with two DHCP servers, a remote site with DHCP services, and a mobile client The client rst connects to the home site and receives an address from one of the two serves He/she then travels to the remote site (without releasing the lease at the home site) and attempts to use the acquired address It is of course NAK’ed and the client receives an address appropriate for the remote site The client then returns home and tries to use the address from the remote site It is NAK’ed but now the client broadcasts a DHCPDISCOVER to get a address The server that holds the previous lease will oer the address back to the client but there is no guarantee that the client will accept that address ; consequently, it is possible for the client to acquire an address on the other server and therefore have two leases within the site The problem can be solved by using only one server per subnet/site and can be mitigated by short lease lengths But in a very mobile environment, it is possible for these transient clients to consume more than their fair share of addresses If departments, oces, or individuals run DHCP servers with their own small address pools on LANs shared by other departments, oces, or individuals, they can nd that their addresses are being used by anyone on the LAN that happens to set their IP conguration to use DHCP An easy mistake to make in setting up a DHCP server is to fail to set all the necessary global parameters This can result in some functions working while others are not, or functions working when the client is set up manually, but failing to work when set to use DHCP Long leases can be disadvantageous in cases where you need to change a conguration parameter or withdraw an address from use The length of the lease can mean the dierence between having to go to every aected client and rebooting it, or merely waiting a certain amount of time for the leases to be renewed (Note : one workaround is to fool with the client computer’s clock) 12 A DHCP relay must in theory always use the same server of destination for the BOOTPREQUEST messages that it receives of a client given Nevertheless an implementation of relay agent which was developed proposes to use a mechanism of Round-Robin for determine towards which DHCP server to send the request Comment on the advantages and disadvantages of this solution Advantage: allows load balancing among multiple DHCP servers Disadvantages: Each time it receives a new BOOTREQUEST message,it relays the message to the next BOOTP server in a list of servers Thus, with this relay agent, multiple consecutive BOOTREQUEST messages from a given client will be delivered todifferent servers Unfortunately, this well-intentioned scheme reacts badly with DHCP [3] and perhaps other variations of the BOOTP protocol which depend on multiple exchanges of BOOTREQUEST and BOOTREPLY messages between clients and servers Therefore, al BOOTREQUEST messages from a given client MUST be relay d to the same destination (or set of destinations) One way to meet this requirement while providing some load-balancing benet is to hash the client’s link-layer address (or some other reliable client-identifying information) and use the resulting hash value to select the appropriate relay destination (or set of destinations) The simplest solution, of course, is to not use a load-balancing scheme and just relay ALL received BOOTREQUEST messages to the same destination (or set of destinations) When transmitting the request to its next destination, the relay agent may set the IP Time-To-Live eld to either the default value for new datagrams originated by the relay agent, or to the TTL of the original BOOTREQUEST decremented by (at least) one 13 It is supposed that IP sub-network share physically the same LAN The stations on each sub-network then will see circulating all the packets diffused on the physic network a) Which problem can occur if two DHCP servers coexist on this shared LAN? Suppose that two sub-IP networks share physically in a same physical support (2 VLANs coexist on the same Ethernet) The stations on each subnet will then see all the packets travel over the network physical dius A computer can be assigned an address of a subnet but does not know a priori which one There may be conflicts during? Access to local resources, such as name servers, NIS server? b) Can one solve the problem? Propose a solution We can define the level of the server (or client for some implementations) the MAC address associated with each IP address and thus define what address will be attributed to a particular machine 14 Why does one define the number of associations (MAC address – IP address) in the of configuration files of DHCP server? Because this limits the number of machines that can transit on the network 15 By basing you on the extract of RFC 1542 whose extracts are given to you in appendix, explain how a DHCP server managing several ranges of addresses will know to choose the IP address in answer to a request Problem A network administrator must reconsider the network plan of his company He must conceive the new network plan detail who will have to allow the automatic attribution of TCP/IP configurations The IP address of the network is 194.12.230.0, but the structure of the network must reflect the organization in distinct departments: Direction and Administrative Departments, Engineer and R&D, Marketing and Commercial Service These domains are connected to a router who is used as link towards the Internet The IP address of this router is fixed and does not belong with any the precedents domain These three departments have currently and respectively of 15, 45 and 12 workstations but the number of workstations is brought to increase in the future Each sub-network will have to allocate the configurations with assistance of distinct DHCP servers In order to make functionary the network in the same breakdown case of one of DHCP servers, the other server must be able to take the relay They must if possible ensure that at least 25 % of the machines will be able to obtain a valid configuration in their sub-network The configurations will have to be static in the case of some machines (server, router…) and dynamic for the others The DHCP servers will have to always obtain highest IP address available in each sub-network, while the links will have the lowest IP address MAC address list of hosts which a fixed address must be allocate: - Administrative DNS Server: 00-32-DE-5A-78-9C - Administrative network link: 1F-7A-90-02-F0-F0 - Administrative network link towards the external router: 1F-7A-90-02-5F-4G - Engineers network link: 2B-14-62-91-C9-B1 Engineers network link towards the external router: 2B-14-62-3F-39-21 Commercial network link: 1C-96-AA-F4-C2-91 Commercial network link towards the external router: 1C-96-AA-14-62-3F Router towards the Internet: 82-F0-06-01-9B-7A In the Administrative department, workstations will have their fixed address An address range of Commercial domain is allocated for the outside connections or the clients visiting in the company This reserved addresses range cover the going addresses from 194.12.230.130 to 194.12.230.140 Propose a mask of sub-network for the network of company 194.12.230.0 is a Class C address, the last byte must be used to encode the numbers of sub-network and the numbers of hosts in each subnet It is necessary to use two bits for three sub-networks the subnet mask is complete: 255.255.255.192 Calculate the total number of host which can contain each sub-network 62 hosts per subnet Affect a number of sub-networks to each department Define the address ranges usable in each sub-network - 194.12.230.0/255.255.255.192 Administrative sub network address range: 194.12.230.1 (00 000001) has 194.12.230.62 (00 111110) - Engineers in 194.12.230.64/255.255.255.192 network address range: 194.12.230.65 (01 000001) has 194.12.230.126 (01 111110) - Commercial network in 194.12.230.128/255.255.255.192 address range: 194.12.230.129 (10 000001) has 194.12.230.190 (01 111 110) - 194.12.230.192/255.255.255.192 in interconnection network address range: 194.12.230.193 (10 000001) has 194.12.230.254 (01 111110) Trace a network diagram of the company by making appear the host of the network and their IP address Define how will be assured the attribution of the IP configurations following a breakdown on one of DHCP servers Argument in particular over the duration of beams Note the possible contradictions with respect to the specification document In case of failure of a DHCP server, hosts must be able to apply a configuration from another DHCP server on a different subnet, the applications in broadcasting sent by these hosts must be able to pass the routers Also, the routers R1 and R2 must be able to route datagrams DHCP (BOOTP) or DHCP relay agent running in each subnet Each DHCP server is assigned a second extended address in another subnet which it provides a kind of replacement in case of failure These tracts "security" must not conflict (have identical addresses) with ranges of addresses from the DHCP server "owner" in the subnet as a risk to award a duplicate address exists Here is a proposal for award of these tracts of security: The Department of Administrative DHCP server provides redundancy for the Department of Commercial The DHCP server provides redundancy department Engineers for the Administrative Department of The DHCP server provides redundancy department Commercial department for Engineers from 107 to 125 (or 18 places or 50% of the total stations) In such a configuration (very limited number of addresses) the length of the leases will be rather long way to limit the number of guests may request a new configuration at a given time The duration can be fixed at 24 hours so as to leave time to reopen the DHCP server Unlike the length of the lease tracts of relief will be rather short to minimize the use of backup servers Define the configuration of servers DHCP for each sub-network: - Extent (beginning and ending addresses, mask) - Lease duration - DHCP options (link by defect, server DNS address) - Addresses to be excluded (+comment) - Reservations to be envisaged (MAC address/ IP address) - Rescue extent of the sub-networks of the department Y - Beginning and ending addresses - Mask - Lease duration - … IP Mobility 2.1 IP Mobile Let a network be constituted of IP mobile terminals which can move in cells A customer is registered in the cell where it took its subscription a) Why its IP address is not sufficient so that the network finds it when it moves? Its IP address is not sufficient because it indicates a sub-network in which the client connects If it moves, its IP address can no longer locate it b) If one gives a new IP address to a user who is not in the cell where it is registered, how can one establish the link between its basic address and its new address? It is called a local agent or home agent, to make the correlation between the local address and the new client's IP address (called address visitor or care-of-address) When a message arrives in the local subnet, the local agent, modifies the destination address indicating the destination address field the address of the care-of-address c) If the user emits a packet, it must use its basic address or the address that the network affected to it? When a client emits a packet must indicate its local address because it changes a new network of visitor, it will not forward the message d) In which case could it be interesting to give a user who wishes to join our customer his temporary address, decreed by the cell in which it is? Rather than always going through the local agent, it may be interesting to give visitors al'emetteur address of the recipient This solution is acceptable if the recipient is not moving and there is enough time in the network access IP Mobile was conceived to function with the non-mobile nodes or the applications of the transparent manner However improvements can be brought to the protocol when the corresponding nodes are informed of the node mobility If a correspondent is able to make the decapsulation IP- in - IP, it could communicate in manner more efficacies with the mobile node and this despite the presence to firewall Why? A mobile node has as principal address 192.68.37.13 and moves in a reception network where the address of its "care of address" will be 145.48.46.123 The "foreign agent " address is 145.48.46.79 and that of its mother agent is 192.68.37.2 a) How the mobile node will detect that it is not any more in its mother network? By receiving prompts foreign agent or no longer receiving messages from his agent mother b) Describe summarily the exchange of frames allowing this detection: The message exchange allowing the mobile node to detect that it is in a reception network is made between _ The message allowing the detection are put in packets (IP/ICMP/UDP) The exchange of messages to the mobile node to detect that it is in a home network is between the foreign agent and mobile node The message can be placed in the detection of UDP packets c) Give the format of the exchanged frames in specifying the @ MAC source and destination (ex: @MAC NM (node mobile) and) and the @ IP source and destination of these messages which allow a mobile node to detect that it is not any more in its mother network: First message MAC Source Address: _ IP Source Address: Second message MAC Source Address: _ IP Source Address: Destination _ Destination _ Destination _ Destination _ Care-of-address a) How could the mobile node be its own Care - of - Address? He received an address of thanks to the DHCP server network Home, but the foreign agent is always present to send messages of Warning b) What are the advantages and disadvantages of this solution? Benefits: routing via the FA, NM dialogue directly via its HA Disadvantages: if there are many mobile node requires that the DHCP server has an IP address range considerably, which is not always possible That is why in the case of management of mobility with IPv4, it uses the IP address of the FA c) In your opinion, must there thus be necessarily a server DHCP by network and must there have an IP address in the same class which constitutes its range of addresses? Not necessarily They have slightly observes their environment d) How can the negotiation be done? The applications should reach the DHCP server that is located on another network, they must pass the routers, which is theoretically not possible It is then necessary to install one or more routers on a relay agent that will intercept requests for the broadcast and transmit a DHCP server known to the agent This relay agent located on the bridge will be the intermediary and the client still managed to obtain an address given by DHCP on a different network, but relayed by the relay agent 2.2 IP version and the mobility management What is the difference between the "traffic class" and "flow label" fields in the IPv6 header? RFC 2460 Label Flow 20 bits in the IPv6 header may be used by a source naming sequences of packets for which special treatment by IPv6 routers request This special treatment could be a different quality of service the default service or service "real time" This aspect of IPv6 is still experimental The hosts or routers that not support the functions of field Label Flow xer have the required field to zero when they are originally meant the package, to pass the field as it stood when they transmit a packet and to ignore the field when they receive a packet Classes trac Trac The Class field of bits in the IPv6 header was created to be used by bare roots and / or routers and transmitters for identication distinguish different classes or priorities of IPv6 packets The Class field Trac offers functionality similar to that of the ToS can be supported by IPv6 It is hoped that these experiments will eventually arrive at an agreement on the kinds of conventional traffic that are most useful for IPv6 packets The following general requirements apply to the Traffic Class field: The service interface of an IPv6 service node must provide a means to an upper layer protocol Plasser bit value Traffic Class for packets from the upper layer protocol The default value should be zero for all bits The service interface of an IPv6 service node must provide a means to an upper layer protocol Plasser bit value Traffic Class for packets from the upper layer protocol The default value should be zero for all bits The nodes that support use specic (possibly experimental or standard) of all or part of the Traffic Class bits are permitted to change the value of these bits in the packets they create, transmit or receive, as required by this use specic The nodes should ignore and leave unchanged any bits of the Traffic Class field for which they not support use specic An upper layer protocol must not assume that the value of bits of the class of traffic in a packet received is the same as the value sent by the source package Trafic Class (8 bits) : Available for use by originating nodes and/or forwarding routers to 10 identify and distinguish between different classes or priorities of IPv6 packets The rst six bits of the trafic class eld are referred to as the DS (differentiated services) field, discussed in Chapter 19 The remaining bits are reserved for an ECN (explicit congestion notication) field, currently in the process of standardization Flow Label (20 bits) : May be used by a host to label those packets for which it is requesting special handling by routers within a network All packets that are to be part of the same flow are assigned the same flow label by the source Explain briefly three types of IPv6 addresses - Unicast : An identifier for a single interface A packet sent to a unicast address is delivered to the interface identied by that address - Anycast : An identifier for a set of interfaces (typically belonging to different nodes) A packet sent to an anycast address is delivered to one of the interfaces identied by that address (the "nearest" one, according to the routing protocols’ measure of distance) - Multicast : An identifier for a set of interfaces (typically belonging to different nodes) A packet sent to a multicast address is delivered to all interfaces identied by that address The IPv6 addresses are long, that will increase the size of the headers and affect the processing time of the IPv6 packets By what these disadvantages are offset in IPv6? With an increase from 32 to 128 bits for IP addresses, an IPv6 header is actually longer than one for IPv4 (40 bytes compared to 20) However, this is greatly offset by the improvements IPv6 offers : - In IPv6, optimization of headers by using optional extension improves packet processing - Prioritizing IPv6 routing reduces the size of routing tables and thus improves router processing times - IPv6 avoids going through NAT type mechanisms and associated proxies - If the problem of the header continues to be important when bandwidth is scarce (case of the radio), it is possible to apply a standardized header compression mechanism When the problem is analyzed as a whole, it appears that with an equivalent processing type (hardware or software) the processing and routing performances are better in IPv6 Are the IPv6 routers more or less efficacy than the IPv4 routers? Router performance primarily depends on the capacity of the router to process packets (forwarding) in hardware There are routers that process IPv6 forwarding in hardware ; their performance is similar to that of IPv4 In addition, header optimization improves performance in IPv6 And, it is not always necessary to process forwarding in hardware, particularly for access routers Processing forwarding in software is possible with current processors, resulting in equivalent performance for IPv4 and IPv6 So IPv4 and IPv6 performances are similar What is each type of IPv6 header used for? Hop-by-Hop Options header : Defines special options that require hop-by-hop processing Routing header : Provides extended routing, similar to IPv4 source routing Fragment header : Contains fragmentation and reassembly information Authentication header : Provides packet integrity and authentication Encapsulating Security Payload header : 11 Provides privacy Destination Options header : Contains optional information to be examined by the destination node All these notations being equivalent a) Deduce the notation rules of the IPv6 addresses into hexadecimal # raw ipv6 address 2001:0000:0234:C1AB:0000:0000:AABC:003F # 2001:0:234:C1AB:0:0:AABC:3F 2001:0:0234:C1ab:0:0:aabc:3F 2001::0234:C1ab:0:0:aabc:003F 2001:0:0234:C1ab::aabc:003F Or even # loopback address 0:0:0:0:0:0:0:1 # can be written as ::1 # all zeros (unspecified a.k.a unassigned IP) 0:0:0:0:0:0:0:0 # can be written as :: b) Can the address 2001:0:0:1:0:0:0:3F be reduced to: 2001::1::3F or 2001:0:0:1::3F? Which differences exist between Mobile IPv4 and Mobile IPv6? The design of Mobile IP support in IPv6 (Mobile IPv6) benefits both from the experiences gained from the development of Mobile IP support in IPv4 (Mobile IPv4) [22, 23, 24], and from the opportunities provided by IPv6 Mobile IPv6 thus shares many features with Mobile IPv4, but is integrated into IPv6 and offers many other improvements This section summarizes the major differences between Mobile IPv4 and Mobile IPv6 : - There is no need to deploy special routers as "foreign agents", as in Mobile IPv4 Mobile IPv6 operates in any location without any special support required from the local router o Support for route optimization is a fundamental part of the protocol, rather than a nonstandard set of extensions - Mobile IPv6 route optimization can operate securely even without pre-arranged security associations It is expected that route optimization can be deployed on a global scale between all mobile nodes and correspondent nodes - Support is also integrated into Mobile IPv6 for allowing route optimization to coexist efficiently with routers that perform "ingress filtering" [26] – - The IPv6 Neighbor Unreachability Detection assures symmetric reachability between the mobile node and its default router in the current location - Most packets sent to a mobile node while away from home in Mobile IPv6 are sent using an IPv6 routing header rather than IP encapsulation, reducing the amount of resulting 12 overhead compared to Mobile IPv4 - Mobile IPv6 is decoupled from any particular link layer, as it uses IPv6 Neighbor Discovery [12] instead of ARP This also improves the robustness of the protocol - The use of IPv6 encapsulation (and the routing header) removes the need in Mobile IPv6 to manage "tunnel soft state" - The dynamic home agent address discovery mechanism in Mobile IPv6 returns a single reply to the mobile node The directed broadcast approach used in IPv4 returns separate replies from each home agent Anycast Addressing In addition to supporting unicast addressing and multicast addressing, IPv6 supports a new type of anycast addressing in the first considering This technique is similar to the multicast in the direction where the destination address is a group of addresses, but instead of trying delivering the datagram to all the members of the group, it tries to deliver to only one member of the group, which is nearest or most capable to receive it You will use a routing algorithm of the OSPF type (state of the links) to build a routing table of the router R3 The metric used represent the availability link (loss, occupancy rate …) More it is raised, less the link is available a) Build the routing table of R3 by taking the data of links on the figure b) In considering now that one wants to introduce the concept of Anycast routing into these tables of routing The idea consists of taking into account the availability of Anycast servers and of automating the choice of the server in allocating them to each one the same Anycast address The availability represents (number of users connected, the memory available, the load CPU…) What will be the consequence on routing the tables? c) Reconstruct the routing table of R3 in order that the access with the server is made on 13 the principal criteria of the availability of the server Annexes 3.0.1 Extract of the RFC 1542 Extract of the RFC 1542 BOOTP Relay Agents In many cases, BOOTP clients and their associated BOOTP server(s) not reside on the same IP network or subnet In such cases, some kind of thirdparty agent is required to transfer BOOTP messages between clients and servers Such an agent was originally referred to as a "BOOTP forwarding agent." However, in order to avoid confusion with the IP forwarding function of an IP router, the name "BOOTP relay agent" is hereby adopted instead ( ) 4.1 General BOOTP Processing for Relay Agents All locally delivered UDP messages whose UDP destination port number is BOOTPS (67) are considered for special processing by the host or router’s logical BOOTP relay agent ( ) Hosts and routers are usually required to silently discard incoming datagrams containing illegal IP source addresses This is generally known as "Martian address filtering." One of these illegal addresses is 0.0.0.0 (or actually anything on network 0) However, hosts or routers which support a BOOTP relay agent MUST accept for local delivery to the relay agent BOOTREQUEST messages whose IP source address is 0.0.0.0 BOOTREQUEST messages from legal IP source addresses MUST also be accepted ( ) 4.1.1 BOOTREQUEST Messages Some configuration mechanism MUST exist to enable or disable the relaying of BOOTREQUEST messages Relaying MUST be disabled by default ( ) If the relay agent does decide to relay the request, it MUST examine the ’giaddr’ ("gateway" IP address) field If this field is zero, the relay agent MUST fill this field with the IP address of the interface on which the request was received If the interface has more than one IP address logically associated with it, the relay agent SHOULD choose one IP address associated with that interface and use it consistently for all BOOTP messages it relays If the ’giaddr’ field contains some nonzero value, the ’giaddr’ field MUST NOT be modified ( ) A relay agent MUST use the same destination (or set of destinations) for all BOOTREQUEST messages it relays from a given client ( ) 4.1.2 BOOTREPLY Messages BOOTP relay agents relay BOOTREPLY messages only to BOOTP clients It is the responsibility of BOOTP servers to send BOOTREPLY messages 14 directly to the relay agent identified in the ’giaddr’ field Therefore, a relay agent may assume that all BOOTREPLY messages it receives are intended for BOOTP clients on its directlyconnected networks When a relay agent receives a BOOTREPLY message, it should examine the BOOTP ’giaddr’, ’yiaddr’, ’chaddr’, ’htype’, and ’hlen’ fields These fields should provide adequate information for the relay agent to deliver the BOOTREPLY message to the client The ’giaddr’ field can be used to identify the logical interface from which the reply must be sent (i.e., the host or router interface connected to the same network as the BOOTP client) If the content of the ’giaddr’ field does not match one of the relay agent’s directly connected logical interfaces, the BOOTREPLY messsage MUST be silently discarded The ’htype’, ’hlen’, and ’chaddr’ fields supply the linklayer hardware type, hardware address length, and hardware address of the client as defined in the ARP protocol [4] and the Assigned Numbers document [6] The ’yiaddr’ field is the IP address of the client, as assigned by the BOOTP server ( ) BOOTP Server Behavior This section provides clarifications on the behavior of BOOTP servers ( ) 5.4 Strategy for Delivery of BOOTREPLY Messages Once the BOOTP server has created an appropriate BOOTREPLY message, that BOOTREPLY message must be properly delivered to the client The server SHOULD first check the ’ciaddr’ field If the ’ciaddr’ field is nonzero, the BOOTREPLY message SHOULD be sent as an IPunicast to the IP address identified in the ’ciaddr’ field ( ) The server MAY choose to ignore the ’ciaddr’ field and act as if the ’ciaddr’ field contains 0.0.0.0 (and thus continue with the rest of the delivery algorithm below) The server SHOULD next check the ’giaddr’ field If this field is nonzero, the server SHOULD send the BOOTREPLY as an IP unicast to the IP address identified in the ’giaddr’ field The UDP destination port MUST be set to BOOTPS (67) This action will deliver the BOOTREPLY message directly to the BOOTP relay agent closest to the client; the relay agent will then perform the final delivery to the client ( ) If the ’giaddr’ field is set to 0.0.0.0, then the client resides on one of the same networks as the BOOTP server 15 ... closest to the client; the relay agent will then perform the final delivery to the client ( ) If the ’giaddr’ field is set to 0.0.0.0, then the client resides on one of the same networks as the BOOTP... will be the consequence on routing the tables? c) Reconstruct the routing table of R3 in order that the access with the server is made on 13 the principal criteria of the availability of the server... home site) and attempts to use the acquired address It is of course NAK’ed and the client receives an address appropriate for the remote site The client then returns home and tries to use the address

Ngày đăng: 17/09/2012, 09:13

TỪ KHÓA LIÊN QUAN