> -----邮件原件----- > 发件人: L3VPN [mailto:[email protected]] 代表 Joe Touch > 发送时间: 2013年12月3日 23:55 > 收件人: Pedro Roque Marques; Henderickx, Wim (Wim) > 抄送: Thomas Morin; [email protected] > 主题: Re: on limitations of draft-xu-l3vpn-virtual-subnet > > > > On 12/3/2013 12:55 AM, Pedro Roque Marques wrote: > > Is the fundamental IP behavior that you are referring to the TTL decrement > between two addresses on the same "subnet" ? > > I believe you are wrong: to my knowledge proxy ARP is compliant with Host > and Router requirement RFCs. > > For IPv4, RFC1812 says that all 1's "limited broadcast" > (255.255.255.255) MUST NOT be forwarded. RFC2644 updates that RFC to say > that even subnet-directed broadcasts MUST NOT be forwarded (as configured > by default). > > So by default, a router would never forward the broadcast for which the proxy > ARP would be an appropriate response. Which would mean that the proxy > would work only if already populated at the router; there would be no means to > forward the initial request if the cache were empty. So proxy ARP would work > if > manually configured, but would be unreliable if automatically populated if > used > on a router that spans two groups of hosts on the same subnet.
Hi Joe, From the above statement (e.g., " there would be no means to forward the initial request if the cache were empty"), it seems that the proxy ARP mechanism you meant is actually the ARP cache mechanism in which the real MAC of the target host is expected to be returned by the "ARP Proxy". In contrast, the ARP proxy mechanism used in this draft is strictly accordance with the definition of the Proxy ARP in RFC1027. That's to say, the ARP proxy would return its own MAC rather than the real MAC of the target host, which means there is no need for broadcasting the ARP requests across the virtual subnet. Xiaohu > Joe
