| < draft-ietf-isis-igp-p2p-over-lan-02.txt | draft-ietf-isis-igp-p2p-over-lan-03.txt > | |||
|---|---|---|---|---|
| Network Working Group Naiming Shen | Network Working Group Naiming Shen | |||
| Internet Draft Acee Lindem | Internet Draft Acee Lindem | |||
| Expiration Date: September 2003 Jenny Yuan | Expiration Date: February 2004 Jenny Yuan | |||
| File name: draft-ietf-isis-igp-p2p-over-lan-02.txt Redback Networks | File name: draft-ietf-isis-igp-p2p-over-lan-03.txt Redback Networks | |||
| Alex Zinin | Alex Zinin | |||
| Alcatel | Alcatel | |||
| Russ White | Russ White | |||
| Stefano Previdi | Stefano Previdi | |||
| Cisco Systems | Cisco Systems | |||
| March 2003 | August 2003 | |||
| Point-to-point operation over LAN | Point-to-point operation over LAN | |||
| in link-state routing protocols | in link-state routing protocols | |||
| draft-ietf-isis-igp-p2p-over-lan-02.txt | draft-ietf-isis-igp-p2p-over-lan-03.txt | |||
| Status of this Memo | Status of this Memo | |||
| This document is an Internet-Draft and is in full conformance with | This document is an Internet-Draft and is in full conformance with | |||
| all provisions of Section 10 of RFC2026. | all provisions of Section 10 of RFC2026. | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF), its areas, and its working groups. Note that | Task Force (IETF), its areas, and its working groups. Note that | |||
| other groups may also distribute working documents as | other groups may also distribute working documents as | |||
| Internet-Drafts. | Internet-Drafts. | |||
| skipping to change at page 5, line 18 ¶ | skipping to change at page 5, line 18 ¶ | |||
| routes using this p2p-over-lan circuit as an outbound interface is | routes using this p2p-over-lan circuit as an outbound interface is | |||
| not optional. The IP nexthop address has to be a valid interface | not optional. The IP nexthop address has to be a valid interface | |||
| or internal address on the adjacent router. This address is used by | or internal address on the adjacent router. This address is used by | |||
| local router to obtain the MAC address for IP packet forwarding. | local router to obtain the MAC address for IP packet forwarding. | |||
| Proxy ARP has to be enabled if the address is not the adjacent | Proxy ARP has to be enabled if the address is not the adjacent | |||
| interface IP address. | interface IP address. | |||
| In the case where unnumbered IP addresses are used for p2p-over-lan | In the case where unnumbered IP addresses are used for p2p-over-lan | |||
| circuit, the source IP address of ARP request and the target | circuit, the source IP address of ARP request and the target | |||
| interface IP address are usually on different subnets. The ARP | interface IP address are usually on different subnets. The ARP | |||
| should reply only if this is a p2p-over-lan circuit and the source | should reply if this is a p2p-over-lan circuit, or an | |||
| IP address of the ARP request is the same as the neighbor's | implementation MAY choose to limit the reply to the case where the | |||
| interface IP address at the other end. The neighbor's address is | IGP peer is requesting over this unnumbered p2p-over-lan circuit. | |||
| learned from IGP hello exchanges over this circuit. | ||||
| 4.4 Other MAC address resolution mechanisms | 4.4 Other MAC address resolution mechanisms | |||
| In more general cases while p2p-over-lan circuit is used as an | In more general cases while p2p-over-lan circuit is used as an | |||
| unnumbered link, other MAC address resolution mechanisms are needed | unnumbered link, other MAC address resolution mechanisms are needed | |||
| for IP packet forwarding. For example, if link-state IGP is not | for IP packet forwarding. For example, if link-state IGP is not | |||
| configured over this p2p-over-lan link, or Proxy ARP is not enabled | configured over this p2p-over-lan link, or if the mechanism described | |||
| on the circuit. The following techniques can be used to acquire the | in section 4.3 is not possible. The following techniques can be used | |||
| MAC address and/or the next-hop IP address of the remote device on | to acquire the MAC address and/or the next-hop IP address of the | |||
| an unnumbered point-to-point LAN link. | remote device on an unnumbered point-to-point LAN link. | |||
| 1. Static configuration. A router can be statically configured | 1. Static configuration. A router can be statically configured | |||
| with the MAC address that should be used as the destination | with the MAC address that should be used as the destination | |||
| MAC address when sending data out of the interface. | MAC address when sending data out of the interface. | |||
| 2. MAC address gleaning. If a dynamic routing protocol is running | 2. MAC address gleaning. If a dynamic routing protocol is running | |||
| between the routers connected to the link, the MAC address of | between the routers connected to the link, the MAC address of | |||
| the remote device can be taken from a data-link frame carrying | the remote device can be taken from a data-link frame carrying | |||
| a packet of the corresponding routing protocol. | a packet of the corresponding routing protocol. | |||
| skipping to change at page 6, line 5 ¶ | skipping to change at page 6, line 5 ¶ | |||
| interface. When such an address is known to a router, the | interface. When such an address is known to a router, the | |||
| router may announce its MAC address by sending a gratuitous | router may announce its MAC address by sending a gratuitous | |||
| ARP message. This solution will also help in the situations | ARP message. This solution will also help in the situations | |||
| where routers calculate the next-hop addresses for the routes | where routers calculate the next-hop addresses for the routes | |||
| through point-to-point interfaces. Since the source IP address | through point-to-point interfaces. Since the source IP address | |||
| in the received routing protocol packet is used as the next- | in the received routing protocol packet is used as the next- | |||
| hop address in the route, forwarding an IP packet along such | hop address in the route, forwarding an IP packet along such | |||
| a route will lead to an ARP request submission on the LAN | a route will lead to an ARP request submission on the LAN | |||
| link that will be answered by the remote device. | link that will be answered by the remote device. | |||
| 4. Broadcast/multicast/proprietary. | ||||
| 4.5 Detection of mis-configuration | 4.5 Detection of mis-configuration | |||
| With this p2p-over-lan extension, the difference between a LAN and | With this p2p-over-lan extension, the difference between a LAN and | |||
| a point-to-point circuit can be made purely by configuration. It is | a point-to-point circuit can be made purely by configuration. It is | |||
| important to implement the mechanisms for early detection of | important to implement the mechanisms for early detection of | |||
| mis-configuration. | mis-configuration. | |||
| If the circuit is configured as point-to-point type and receives | If the circuit is configured as point-to-point type and receives | |||
| LAN hello packets, the router MUST discard the incoming packets; If | LAN hello packets, the router MUST discard the incoming packets; If | |||
| the circuit is a LAN type and receive point-to-point hello packets, | the circuit is a LAN type and receive point-to-point hello packets, | |||
| End of changes. 7 change blocks. | ||||
| 15 lines changed or deleted | 11 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||