Hi all, >Hi bill, Hi Stig, Hi *, > >bill fumerola <[EMAIL PROTECTED]> writes: > >> On Fri, Aug 31, 2007 at 03:58:54AM +0200, Stig Venaas wrote: >>> I'm not arguing for keeping source routing here, but one quite useful >>> thing it can be used for is traceroute. You can for instance trace from >>> a remote point in the network towards yourself. This can be very helpful >>> when debugging routing problems. > >First, thank you both for the feedback. > >Having spent quite some time doing that on the IPv6 internet, i basically >got to the conclusion that if you don't precisely know the router you >send your packets to (the waypoint that will bounce your traffic based >on RH content), you spend more time debugging the reaction of that >router than what happens on the path.
First, a qualifier: my own IPv6 knowledge and experience is and has been (and FWIW will likely remain) in R&D, not operations. That said, the above point seems brilliant in its simplicity. The effectiveness of traceroute from A <-> B would have to be delimited by the intermediate nodes(s) 'willingness' &/or ability to forward these IPv6 packets (containing RH0), as well as the destination's 'willingness' &/or ability to process them. _Not_ rhetorical: I'm wondering how often (and what percentage of times) such a use of RH0 would have to be successful in order for it to be (at least generally) considered an example of a valid use case. There are routers that drops >traffic, others that reply with ICMPv6 error packets indicating an >administratively prohibited condition, others that don't have a route to >your next destination, others that do have a route (default ?) but which >won't go far, etc > >When you include multiple waypoints, this gets even more difficult to >get some precise information (Even if your tool does not try to be smart >on what comes back). > >I understand the interest and like the boomerang traceroute too but i'm >surprised network operators do not have better tools than that to debug >and monitor things. > >> engineers also can use it when setting up, debugging, or for periodic >> testing of peering sessions to make sure that the other side isn't doing >> anything against the contractual terms of the peer (e.g. overriding the >> normal policies that result from standard RIB->FIB route selection). >> >> examples: >> http://ptd.mbo.ma.rcn.net/peerinfo/ >> >> All peers are requested to enable LSRR on router interfaces facing RCN >> peering sessions to facilitate network diagnostics at least during session >> activation. >> >> http://www.via.net/support/support_peer.html >> We require that our peers permit LSR, loose source routing, at least at the >> border. >> >> http://www.noc.wiscnet.net/peering/ >> We require that our peers permit LSR, loose source routing, at least at >> the border for diagnostic purposes. > >Some questions: > >- can anyone send LSR traffic to those routers? is it limited? >- If it is limited in some way, how is it done? >- What tools do you use to test that and what is the frequency of use? > (Only traceroute when you have a doubt?) > >> i don't have an ACM account, but: >> http://portal.acm.org/citation.cfm?coll=GUIDE&dl=GUIDE&id=1016718 > >Don't have either. I won't give credit only based on the abstract ;-) > >> without comparable functionality in IPv6, we lose a feature actively in >> use (through IPv4) by some networks for verification of proper peering. > >Is there any place one can ask operators or people that provide peering >at exchange points on that. Basically, my question is: is there any >consensus on the use of source routing among those people? I know people >that prohibit their use. > >> if i'm out of touch with current policies on peering & LSRR, please let >> me know. > >a+ > Best Regards, Tim Enos Rom 8:28 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
