Hi Ron, On 7/1/2016 9:47 AM, Ronald Bonica wrote: > Hi Joe, > > Good to hear from you! Responses inline.......
Same here on both counts... > > Ron > >> First, IP addresses can be assigned to interfaces or hosts. Interfaces don't >> have to have IP addresses, esp. point-to-point interfaces or those used >> "anonymously" (e.g., for broadcast send/receive). > [RB ] > Absolutely. In the draft, we talk about "unnumbered interfaces". These are > interfaces to which an IP address has not been assigned. I'm talking about numbers assigned to the host, not the interface. What kind of response are you expecting there? ... >> AFAICT, you can't find out anything that ICMP hopcount-exceeded wouldn't >> report. The only difference is that you can control the target better and >> that >> the response comes back as an Echo-reply (which might be less likely to be >> blocked than hopcount-exceeded). > [RB ] > There is another difference. In order to determine the status of the probed > interface using hopcount-exceeded, you have to make the probe packet traverse > the probed interface. This may not be possible. This is why we need both > (traditional) ping and traceroute today. That'd be useful to include in the justification for this (if not already there - I haven't scanned it that deeply). > >> Third, the destination interface and probed interface need to share the same >> network stack, not just be on the same node. There are network stacks that >> isolate processing for different interfaces, which might not be able to see >> the >> state of other interfaces inside the same machine. > [RB ] > Not always. For example, in our implementation, it is possible to identify > the destination by IPv4 address and the probed interface by IPv6 address. Yet > IPv4 and IPv6 are different network layer protocols. I'm referring to software stack, not protocol-compatibility stack. FreeBSD allows you to deploy multiple independent stacks associated with different subsets of interfaces and addresses -- a stack that implements this solution might not be capable of exchanging information between software stacks. ... > >> Additionally, I think this might have an existing equivalent when the probed >> interface has an address, e.g., it really seems like it ought to be >> equivalent to >> an IP with LSR whose destination IP is the "destination" and whose probe IP >> is the LSR "next hop". In a sense, it seems like you're just extending ping >> with >> LSR that allows for using ifName, ifIndex, or non-IP addresses rather than >> just IP addresses. It might be useful to describe that way, FWIW. > [RB ] > I'm not sure that I follow this paragraph. Let's say a device has two interfaces with addresses A and B. I might not be able to ping address B because of routing between me and that device. However, I might be able to ping B via a LSR through A. Isn't that largely how this IDs approach works when you're using a single AF with numbered interfaces? >> Also, IMO, the "hopcount" of this test ought to be decremented by 1 if the >> probed interface is not the received interface. Otherwise, you'd be reporting >> the same hopcount for the incoming interface and forwarded outgoing >> interfaces, which doesn't seem right to me. > [RB ] > Just to be specific, which packet should have its hopcount decremented and by > which node? Hops account for relaying, not link traversal (RFC1812). Hopcount should always be decremented during the relaying process. That means when it arrives at a node, the hopcount is NOT decremented before accepting it on the address of the incoming interface, but IMO it really ought to be decremented before accepting it on the address of an outgoing interface. Joe _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
