Round-trip traceroute is useful inside intra-domain environments as you note, where ingress filtering isn't generally deployed. Hence it works in many places today and it can be very useful for debugging.
Also, as noted in the original PDF that started this thread, Windows (and I think at least one other OS if I remember the PDF correctly) supports RH for compliance, but already disables RH by default. Since that's already the deployed behavior of many hosts, I'd support the disabled-by-default as the best choice. -Dave > -----Original Message----- > From: Pekka Savola [mailto:[EMAIL PROTECTED] > Sent: Monday, April 30, 2007 12:43 AM > To: Dave Thaler > Cc: Jari Arkko; IETF IPv6 Mailing List > Subject: RE: Question for IPv6 w.g. on [Re: IPv6 Type 0 Routing > Headerissues] > > Hi, > > On Fri, 27 Apr 2007, Dave Thaler wrote: > > Two scenarios that are much less harmful are > > when there is only 1 address in only one RH0: > > 1) when the intermediate destination address and the final > > destination address are addresses of the same node. > > 2) when the final destination address is equal to the > > source address. > > > > In both cases, the intermediate destination isn't being > > used as transit between two other nodes. A sample use > > case of the second scenario is for a round-trip > > traceroute. > > FWIW, I personally think 2) [turn off by default everywhere] seems > like the best choice, but I think 1) [deprecate] would also be OK. I > wouldn't mind 4) but I wonder if it's worth the trouble. > > Some IPv4 perspective: > ---------------------- > > IPv4 specifications (RFC 1812) require source routing to be enabled on > routers by default (a MUST). IPv4 hosts MAY process routing headers > (RFC 1122) and there are some specifications what should happen. It > seems that -- specification-wise -- the same attacks as exist for IPv6 > (multiple routing headers, multiple waypoints) are possible with IPv4 > as well. > > IPv4 specifications also require that a host MUST reverse the routing > header if they're a final recipient (leading to a symmetric return > path). (IPv6 specs allow reversing only if RT header was > authenticated) > > Because attacks would likely be possible using v4 source routing as > well -- unless implementation defaults differ significantly here -- > we should be able to walk, not run, to a decision. > > Similarly, a decision should likely affect IPv4 as well. > > Some operations perspective: > ---------------------------- > > Please remember that using source routing for 'reverse path > traceroute' is only possible if networks don't implement > ingress/egress filtering. > > As such, I cannot support the 'reverse path traceroute' usage scenario > for source routing, because doing so shouldn't work in the first place > in well-operated networks, and could be yet another roadblock to > appropriate filtering. > > The other scenario Dave mentions is AFAICS the one where type 2 > routing header was designed for, and could probably be used in that > scenario as well, even if MIPv6 was not used. > > A couple of folks mentioned using routing header for traffic path > selection (in the middle of the network). That also interferes with > ingress/egress filtering, but not quite as badly. This is probably > mostly useful for research purposes and I'm having difficulty seeing a > business case for doing this in production. > > The reason why I'd prefer disabling instead of complete deprecation is > that I can imagine use cases where source routing can be a useful > diagnostics tool inside one administrative domain, and if we deprecate > it, it's gone for good (unless we define a new type, and transition to > it would take a long time). > > On the other hand, given that these usage cases are rather limited, I > don't think they're in wide use, and still cause problems for > ingress/egress filters, I'm also ok with deprecation. > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
