Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

IPv6 Routing Header - How does it work?



Hi Patrick,

Thank you very much for your detailed explaination :)


----- Original Message -----
From: "Patrick R. McManus" <mcmanus at ducksong.com>
To: "Vriz" <vriztll at hotmail.com>
Cc: "__Boston Linux Mail List" <discuss at blu.org>
Sent: Friday, April 19, 2002 10:46 AM
Subject: Re: IPv6 Routing Header - How does it work?


> [Vriz: Fri, Apr 19, 2002 at 10:29:13AM +0800]
> > I see. Actually, I'm not trying to state a route for my packet to go.
> > It's just that I would like to find out the route my packet has taken
from a
> > source to a destination.
> > If I'm not wrong, I think traceroute in linux does that. However, I
would
> > like to know how it is done.
>
> ah! This is a much easier question!
>
> yes, traceroute shows you the path your packets take from you to the
> destination.
>
> It does this by manipulating the TTL (time to live) field in the IP
> header. TTL (in practice) specifies the maximum number of hops a
> packet may travel. Each time a router forwards a packet it reduces the
> TTL by one (technically max(1,# sec q'd at router), but generally
> implmented as just 1) - if a packet has a TTL of 0 it gets dropped and
> the original sender is notified via an ICMP_TIME_EXCEEDED ICMP
> message. The normal purpose for a TTL is to prevent loops from filling
> the network with endlessly forwarded packets.
>
> traceroute starts out by sending its probe with a TTL of just 1. The
> first router gets the packet, decrements the TTL and discovers that it
> can't forward it anymore - so it sends the ICMP notification to the
> original sender and drops the packet. The original sender uses the src
> address of that ICMP message to identify the first hop router. It then
> repeats the process with a TTL of 2 to find the second hop router,
> etc..
>
> There are a whole slew of reasons why this fails to work now and again
> in practice (links that filter icmp, and routers using private rfc 1918
> address space combined with links that filter private addresses being
> the 2 most common.), but its a pretty good technique overall.
>
> when this works, this tells you the path from your src to the
> destination. It doesn't tell you anything about the path from the
> other end towards you - and asymmetric paths are common. Figuring the
> latter out is much trickier.
>
> > And if my packet has travelled from a source to a destination using a
> > specific route, does that mean it's going to be more or less unchanged
for
> > my other packets (same source and destination)?
>
> they call this 'fate sharing' - and you can assume this with a
> fair degree of certainty - but its hardly absolute. There is some
> routing that takes port numbers into account, as well as switches and
> routers that simply load balance their traffic - but the latter
> introduces reordering (you send packets 1,2,3 and they arrive 1,3,2)
> which has a bad impact on tcp performance and so networks try and
> engineer so that doesn't happen too much.
>
> -Patrick
>
>
>
> _______________________________________________
> Discuss mailing list
> Discuss at blu.org
> http://www.blu.org/mailman/listinfo/discuss
>




BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org