I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Summary: ready with nits The Security Considerations section seems mostly adequate, assuming that it is an acceptable risk to use address-based filtering. I am a little concerned about the wording of the destination address checks on the proxy ping requests. Shouldn't the Proxy LSR know what its own addresses are, and explicitly check for them? Does "Martian" filtering refer to all undesired destination addresses, or just reserved ones? There seems to be no citation for the term "Martian address" as used in sections 3.2 and 6 of this document; RFC 3704 comes close. If that definition is appropriate here, perhaps this document should cite RFC 3704? I think I have also heard "Martian" used more expansively to refer to other address blocks that should not be routed, despite not being formally reserved (e.g., unallocated by the responsible registry). Perhaps that definition is more appropriate. Editorial: The use of destination addresses in range 127/8 seems odd to me, but I eventually found that RFC 4379 allows the use of such loopback range addresses for the LSP echo requests. Is this correct? It might be good to briefly explain that unusual usage. Also, I am not too familiar with the special IPv6 address ranges, but it seems that ::FFFF:7F00:0/104 is a IPv4-mapped loopback range, and therefore is equivalent to the 127/8 IPv4 range mentioned earlier. I don't know whether you need to call this out specifically. Also, RFC 4379 uses the notation ::FFFF:127/104. I'm not sure which of those notations is preferred for IPv4-mapped addresses.