TTL modification while routing IP packets

  • Thread starter Thread starter Jakub Lida
  • Start date Start date
J

Jakub Lida

Hello,

Is it possible to modify the TTL of packets that are being forwarded by a
Windows 2000/2003 router? I mean re-setting TTL for them or ensuring that
it is not lower/higher than a specified value (as it is possible for
example in OpenBSD's pf filter with a "scrub all reassemble tcp min-ttl
2").

Thank you very much for your help!

Kuba <[email protected]>
Krakow, PL
 
Jakub Lida said:
Hello,

Is it possible to modify the TTL of packets that are being forwarded by a
Windows 2000/2003 router? I mean re-setting TTL for them or ensuring that
it is not lower/higher than a specified value (as it is possible for
example in OpenBSD's pf filter with a "scrub all reassemble tcp min-ttl
2").
Click to expand...

Anything is "possible" but the is no built in facility
for that and it seems rather silly since the OWNER
(authoritative servers) for the zone decides the
correct TTL for his own records.

Their are settings on MS DNS Server and Client DNS
cache that sets a MAXIMUM however (I believe).

The clients default to 1 day max rather than the actual
value of the TTL (if it is greater.)
 
Don't confuse IP packet TTLs with DNS record TTLs, they're different. The
OP is asking about Windows RRAS routing functionality for IP packet TTLs.

Jakub, there's no facility in Windows that will let you do this. RRAS does
what any router should: it decremets the TTL by one when it forwards a packet
across an interface. You can't change or alter this behavior. Why do you
need this functionality?

Steve Riley
(e-mail address removed)
 
Steve Riley said:
Don't confuse IP packet TTLs with DNS record TTLs, they're different. The
OP is asking about Windows RRAS routing functionality for IP packet TTLs.
Click to expand...

Excuse me.

For some (strange) reason, I though the question
was about DNS.

Jakub, there's no facility in Windows that will let you do this. RRAS does
what any router should: it decremets the TTL by one when it forwards a packet
across an interface. You can't change or alter this behavior. Why do you
need this functionality?
Click to expand...

Aren't the modern default VERY high anyway?
 
It's ok, Herb, this way we know you're human, like (most of) the rest of
us :)

Long time ago 30 was a de facto TTL used in a lot of devices. We set the
default TTL in Windows NT 3.51 to 32. Starting with NT 4.0 we increased the
default TTL to 128, which is still where it is today.

You can change the default, if you wish, with the "DefaultTTL : REG_DWORD"
key in the "Tcpip\Parameters" branch. The range can be from 1 to 255. Of
course, this applies only to packets that the computer generates. RRAS follows
its normal decrement-whatever-the-current-is-by-1 behavior when forwarding
packets.

Steve Riley
(e-mail address removed)
 
Steve Riley said:
It's ok, Herb, this way we know you're human, like (most of) the rest of
us :)

Long time ago 30 was a de facto TTL used in a lot of devices. We set the
default TTL in Windows NT 3.51 to 32. Starting with NT 4.0 we increased the
default TTL to 128, which is still where it is today.
Click to expand...

That's what I remembered. It was 30, then one day I
blinked and it was 128.
You can change the default, if you wish, with the "DefaultTTL : REG_DWORD"
key in the "Tcpip\Parameters" branch. The range can be from 1 to 255. Of
course, this applies only to packets that the computer generates. RRAS follows
its normal decrement-whatever-the-current-is-by-1 behavior when forwarding
packets.
Click to expand...

In order to have >128 be useful, it would imply he is trying to
reach a destination more than 128 routers away. What is that,
Alpha Centauri, or Andromeda?
 
Logical assumption, but one flaw: no one has yet developed an interplanetary
routing protocol. Once we see a spec for, um, IPRP (hehe), then these enormous
TTLs might make sense. :)

Steve Riley
(e-mail address removed)
 
Steve Riley said:
Logical assumption, but one flaw: no one has yet developed an interplanetary
routing protocol. Once we see a spec for, um, IPRP (hehe), then these enormous
TTLs might make sense. :)
Click to expand...

Oh, I think a simple modification or two to the existing
RFC 1149 might do the trick:

RFC 1149 - Standard for the transmission of IP datagrams on avian carriers
http://www.faqs.org/rfcs/rfc1149.html

And the update for QoS (although not nearly as humorous):
RFC 2549 - IP over Avian Carriers with Quality of Service
http://www.faqs.org/rfcs/rfc2549.html
 
That's because quality of service is no laughing matter.

I sense it's time for another extension of RFC 1149, perhaps thusly:

RFC 3996: Encapsulating Carrier Routing of Avian Protocols (ECRAP)

Introduction. There exists, with the recent development of inhabited orbital
platforms and the obvious follow-on of planetary colonization, the development
of a protocol for effective routing and transport of IP datagrams between
celesital bodies. In the spirit of cooperation, we propose to extend an existing
transport mechanism rather than blindly develop yet another non-standard
one. Therefore, we suggest a method for encapsulating avian carriers inside
spherical Lexan (or similar material) capsules that provide a fully-sustainable
living environment while at the same time affording a kick-ass view. We recommend
rapid and complete adoption of this proposed standard because many current
users of the Internet and other related networks have an unassailable desire
to get the hell away as fast as possible.

LOL

Steve Riley
(e-mail address removed)
 
Back
Top