jessLAND notes - ip
Ipv4 - Internet Protocol v.4
****************************
1. Gral. Info.
2. IP packet format
3. IPv4 address space
4. Unicast
5. Broadcast
6. Multicast
7. Port numbers
8. Fragmentation
9. Subnetting (CIDR, VLSM, ...)
10. ECN - Explicit Congestion Notification
100. OS ttl values
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
^ TOP ^
1. Gral. Info.
==============
- RFC 791: IP Protocol Specification
RFC 1122: Requirements for Internet Hosts -- Communication Layers
(Host behavior in case of pkt anomaly: discard, notify, ...)
- IP Layered Model : Physical / Link / Network / Transport / Application
The IP protocol defines the Network layer behaviour.
...............................................................................
^ TOP ^
2. IP packet format
===================
[Note: letter 'b' right after a number will stand for byte: 4b = 4 bytes]
( IP HEADER: 20b [ + options <= 40b ] ; min. 20b , max. 60b )
( DATA: min. 0b , max. 65515b ; variable)
( IP pkt: min. 20b , max. 65535b -- RFC791)
0 8 16 24 31
+-------+-------+---------------+-------------------------------+
|IP vers|hdr len| TOS | total length / fragment length|
|-------+-------+---------------+-+--+--+-----------------------+
32 | id number |R|DF|MF| fragment offset |
|---------------+---------------+-+--+--+-----------------------+
64 | ttl | protocol | header checksum |
|---------------+---------------+-------------------------------+
96 | src IP |
|---------------------------------------------------------------+
128 | dst IP |
|---------------------------------------------------------------+
160 ~ options field (var. length - max. 40b - 0 padding to 4b mult.)~
|---------------------------------------------------------------+
~ DATA (zero padding to 4 byte multiple) ~
+---------------------------------------------------------------+
[ Check RFC1122- 3.2 for correct system behavior in case of field anomaly ]
+ IP vers: In case of invalid value, dgm must be silently discarded (RFC1122).
+ hdr len: Length of the IP header counted in 32-bit quantities
Values: min. 5 (20 byte hdr) - max. 16 (60 byte hdr)
(The possible length of the IP hdr is limited by this field)
This does not include the data field.
+ TOS - Type Of Service - RFC 1349 Differentiated Services Byte
(TOS future versions)
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-----------+----------------+---+ +-----------------------+---+---+
| Precedence| TOS |MBZ| | |ECN|CE |
+-----------+----------------+---+ +-----------------------+---+---+
- Precedence: Is a measure of the nature and priority of this datagram.
Used by routers to determine which pkt to send first in
case of pkt queues.
0 (000) Routine (Normal) 4 (100) Flash override
1 (001) Priority 5 (101) Critical
2 (010) Immediate 6 (110) Internetwork control
3 (011) Flash 7 (111) Network control
- TOS (Type Of Service): Used by routers to select routing path when
multiple paths are available.
0 (0000) Normal service
1 (0001) Minimize monetary cost (nntp)
2 (0010) Maximize reliability (snmp, routing protocols)
4 (0100) Maximize throughput (ftp-data)
8 (1000) Minimize delay (ftp, telnet)
15 (1111) Maximize Security - RFC 1454
RFC 1349 states that other values are possible although
it does not define its semantics.
- MBZ: Reserved for future use ("must be zero" unless participating
in an Internet protocol experiment which use this bit)
- ECN/CE: RFC 2481
The two low order bits of TOS field are used for Explicit
Congestion Notification, to allow routers to do Random Early
Detection (RED) of the possibility of pkt loss.
When a router is experiencing congestion, and the sender is
ECN aware, router will return pkt to sender with CE set.
Only available for tcp (as 2001) - See TCP reserved flags.
ECN: Sender is ECN aware
CE: Router is experiencing Congestion
+ total length / fragment length:
- if pkt is not fragmented, total length of datagram (including header).
- if pkt is fragmented, size of fragment (including header).
The maximum length is determined by the 2 bytes of the length field in the
IP header: 0 - 65535.
It is recommended that hosts only send datagrams larger than 576 octets if
they have assurance that the destination is prepared to accept the larger
datagrams.
+ id: ip pkt # (0 -> 65535)
. Used to reassemble fragmented IP packets (all fragments same id)
. Usually incremented by one for each datagram sent by the host (even
retries), but it depends on the OS (random,random increments,...)
. Should wrap around and start again after 65535.
. Some OSs (Linux 2.4, IOS 12.0+) set it to 0 if DF is set (not i
needed if the pkt is not going to be fragmented).
+ R: Reserved
+ DF: Don't Fragment
+ MF: More Fragments
+ fragment offset: Offset of the fragment counted in 8-byte quantities.
+ ttl: time to live (0 -> 255)
Initial ttl is generated by the OS and may vary among platforms.
Each router the pkt traverses decrements its ttl by 1
Routers discard pkts with ttl 0 and elicit ICMP time exceeded.
+ header checksum:
. RFC 1071
. The algorithm divides the data to be checksummed into 16-bit fields.
· Each 16-bit field has a 1's complement operation done on it and each of
these 1's complements values are added.
· Validated (and recalculated after decrementing ttl) along the path from
src to dst by each router it passes, and by the dst host.
· If checksum is wrong, the datagram is discarded silently.
· The operation is commutative: chksum 1's complement sum = 1's complement
of hex sum
· It's possible for the 16-bit fields to be swapped and yet the checksum
will remain the same.
- IP OPTIONS:
-----------
[ More info: http://www.isi.edu/in-notes/iana/assignments/ip-parameters ]
+ IP options are rarely used and are usually ignored by most routers.
+ 0-padded to 4 bytes boundary
+ Formats:
1. type (1b)
2. type (1b) + length (1b) + option data (var)
0 (type) 8 16 24 31
+-+-+-+----------+---------------+-------------------------------+
|C|CLS| opt# (5b)| Length | Option Data (var) ~
+-+-+-+----------+---------------+-------------------------------+
- type: · Option byte: Copied (1bit) + CLass (2bit) + option # (5bit)
· copied: option is copied into all fragments on fragmentation:
0 - not copied ; 1 - copied
· class: 0 - control ; 1 - Rsvd. for future use
2 - debugging and measurement ; 3 - Rsvd. for future use
- Length: length in bytes of option field
+ Type Length Contents
---- ------ --------
0x00 EOOL End of Option List 1b [ 0x00 ]
0x01 NOP No Operation 1b [ 0x01 ]
0x07 RR Record Route var (See below)
0x0A ZSU Experimental Measurement
0x0B MTUP MTU Probe (obsolete)
0x0C MTUR MTU Reply (obsolete)
0x0F ENCODE
0x44 TS Time Stamp (record routers' var (See below)
time stamps - up to 9)
0x52 TR Traceroute
0x82 SECURITY Security 11b (See below)
0x83 LSRR Loose Source Route var (Same as RR-See below)
and Record Route
0x84 LSRR_E
0x85 E-SEC Extended Security
0x86 CIPSO Commercial Security
0x88 SATID SATNET Stream Id. 4b [0x88|0x02|stream id (2b)]
0x89 SSRR Strict Source Route var (Same as RR-See below)
and Record Route
0x8E VISA Experimental Access Control
0x90 IMITD IMI Traffic Descriptor
0x91 EIP Extended Internet Protocol
0x93 ADDEXT Address Extension
0x94 RTRALT Router Alert
0x95 SDB Selective Directed Broadcast
0x96 NSAPA NSAP Addresses
0x97 DPS Dynamic Packet State
0x98 UMP Upstream Multicast Pkt.
0xCD FINN Experimental Flow Control
- Most common IP options format:
+----+---+---+-------+--+--+---+
0x44 TS Time Stamp var |0x44|len|ptr|ofw|flg|IP|TS|...|
+----+---+---+-------+--+--+---+
1b 1b 1b 4b 4b var
+----+----+---+----+----+---+
0x82 SECURITY Security 11b |0x82|0x0B|Sec|Comp|Hand|TCC|
+----+----+---+----+----+---+
2b 2b 2b 3b
+----+---+---+--------//-------+
0x07 RR Record Route var |0x??|len|ptr| IP1,IP2,...,IP9 |
0x83 LSRR Loose Source Route & RR +----+---+---+--------//-------+
0x89 SSRR Strict Source Route & RR 1b 1b var
+ dst IP in the IP hdr is the first router IP addr.
The real destination is last IP in the options list.
+ len(gth): includes 0x??, excludes padding bytes
+ ptr: pointer to next router to be used (points to byte #
in this SR option starting by 1 - not 0 -).
Incremented by 4 after traversing a router of the list
+ source routing tools: traceroute, tracert, netcat
...............................................................................
^ TOP ^
3. IPv4 address space
=====================
- 4.2 billion unique IP addresses
- Network classes:
0 - 127 -> Class A (Unicast)
128 - 191 -> Class B (Unicast)
192 - 223 -> Class C (Unicast)
224 - 239 -> Class D - Multicast
240 - 255 -> Class E - Reserved for future use
- See: http://www.iana.org/assignments/ipv4-address-space
- Most common reserved private networks - RFC 1918:
+ Class A: 10.0.0.0 -> 10.255.255.255 Nmask: 255.0.0.0
+ Class B: 172.16.0.0 -> 172.31.255.255 Nmask: 255.255.0.0
+ Class C: 192.168.0.0 -> 192.168.255.255 Nmask: 255.255.255.0
...............................................................................
^ TOP ^
4. Unicast
==========
- Unicast: A frame is destined for a single host.
...............................................................................
^ TOP ^
5. Broadcast
============
- RFC 919
RFC 922 - BROADCASTING INTERNET DATAGRAMS IN THE PRESENCE OF SUBNETS
- Broadcast: A frame is destined for every host on the cable.
- Broadcasting and multicasting only apply to UDP (TCP is connection oriented).
- Broadcast Types:
+ Limited Broadcast:
- Broadcast address: 255.255.255.255
- NEVER forwarded by a router.
- Most BSD systems send L.B. only through the first NIC.
+ Net-directed Broadcast:
- Broadcast address: netid.255.255.255 (A) / netid.255.255 (B)
/ netid.255 (C)
- A router must forward a net-directed broadcast by default, but must
have an option to disable this forwarding.
+ Subnet-directed Broadcast:
- For subnetted networks.
- Broadcast address: subnetid.255.255 (A) / subnetid.255 (B)
Depending on the subnet mask, this will be a
broadcast or not.
- A router must forward these broadcasts if, in fact, they are
broadcasts.
- In a CIDR domain, indistinguishable from Net-directed broadcasts.
+ All-subnets-directed Broadcast:
- For subnetted networks (if not, net-directed broadcast).
- Broadcast address: subnetid.255.255.255 (A) / subnetid.255.255 (B)
- Meaningless for CIDR networks. Obsoleted by multicasting.
Never really implemented.
- e.g. if the 100.0.0.0 net is subnetted in 100.0.0.0/9 & 100.128.0.0/9,
sending a 100.255.255.255 bcast would actually be directed to 2
different subnets, thus "all-subnets-directed broadcast".
+ Notes:
+ In a CIDR world, there are only 2 types of broadcasts:
limited & net-directed
+ Windows will not answer to an ICMP echo request broadcast
+ Most BSD hosts treat the 255.255.255.255 address as an alias of the
first interface that was configured, thus not having a way to broadcast
to all available interfaces (the application must determine which they
are and broadcast on all of them).
- Gateways and Broadcasts:
+ "Never broadcast a dg on the hardware network it was received on".
Neccesary to avoid repeating dg that a gw has heard from itself &
to avoid loops if there are several gws on a hardware network.
+ If a gw receives a directed broadcast for a network to which it is not
connected, it simply forwards it using the usual mechanism.
+ If a gw receives a local broadcast dg, there are several for a network to
which it is connected:
- If the dg is received on the hw network to which it is addressed, then
it should not be forwarded. However, the gw should consider itself to
be a destination of the dg (e.g, it might be a routing table update.)
- If the dg is addressed to a hw network to which the gw is connected, it
should be sent as a (data link layer) broadcast on that network (i.e.
translate the directed broadcast to limited in the applicable interface)
Again, the gw should consider itself a destination of the dg.
- Otherwise, the gw should use its normal routing procedure to choose a
subsequent gateway, and send the datagram along to it.
- Limited Broadcasts and the link layer:
+ Limited broadcasts are sent to all systems on the local network.
+ On bus technologies like Ethernet, broadcast delivery can be accomplished
with a single pkt. On networks composed of switches with point-to-point
connections, sw must implement broadcasting by forwarding copies of the pkt
across individual connections until all switches have received a copy.
+ An limited broadcast frame on ethernet media has a destination IP address
of 255.255.255.255 and a destination MAC address of ff:ff:ff:ff:ff:ff
- Typical limited broadcast uses:
+ DHCP / bootp
+ NetBIOS over IP (location of particular services)
- IP Broadcast forwarding:
+ Some routers have the ability to forward limited broadcasts to other
hosts or networks, to help source hosts locate a certain service (e.g.
DHCP server) located in a different network segment.
+ Typically, if the desired service resides in a particular host (e.g.
DHCP server), the IP of that host is provided to the *helper*.
Alternatively, the broadcast address of the LAN segment will be used
(e.g. if there are several DHCP servers in that network segment).
+ Cisco implements this feature by means of the "ip helper-address" command.
(See related note gral/ios -> ip helper)
+ Some applications require more advanced forwarding capabilities (e.g.
broadcasting to a large number of hosts). Using the standard broadcast
forwarding helper is inefficient, and can overwhelm the router.
This applications use advanced techniques such as:
· udp flooding
· broadcast-to-multicast replication
For a case study, see:
http://www.cisco.com/univercd/cc/td/doc/cisintwk/ics/cs006.htm
...............................................................................
^ TOP ^
6. Multicast
============
- Related Notes: networking/multicast-addresses
- RFC 1054 - Host Extensions for IP Multicasting
- Refs: + INTERNET MULTICAST ADDRESSES
http://www.iana.org/assignments/multicast-addresses
- Multicast: A frame is destined for a set of hosts that belong to a multicast
group.
- Internet Multicast Addresses (class D): 224.0.0.0 -> 239.255.255.255
- Characteristics:
+ Not connection oriented: pkt loss & out of order delivery are possible
Thus, multicasting only applies to UDP.
+ A multicast group is identified by a class D address.
+ Hosts can join or leave a multicast group at any time.
+ Hosts can be members of more than one multicast group.
+ Hosts don't have to belong to a group to send msgs to that group.
- Facts:
+ Multicasting pretends to avoid the unnecesary load produced by a broadcast
in non implied machines.
- Multicast Protocols:
+ IGMP is the protocol that hosts use to communicate with their immediate
neighboring multicast routers.
+ Multicast routers must run a multicast routing protocol, such us:
· DVMRP
· PIM
- Internet Multicast Addresses: 224.0.0.0 -> 239.255.255.255
http://www.iana.org/assignments/multicast-addresses
224.0.0.1 All Systems on this Subnet
224.0.0.2 All Routers on this Subnet
224.0.0.4 All DVMRP Routers on this Subnet
224.0.0.5 All OSPF Routers on this Subnet
224.0.0.6 All OSPF designated Routers on this Subnet
224.0.0.9 All RIP2 Routers on this Subnet
224.0.0.13 All PIM Routers on this Subnet
224.0.0.15 All CBT Routers on this Subnet
224.0.1.1 Network Time protocol (NTP)
224.2.0.0 -> 224.2.255.255 - Multimedia Conference Calls
[...]
...............................................................................
^ TOP ^
7. Port numbers
===============
- Port ranges:
0 -> 1023 - Well Known Ports
1024 -> 49151 - Registered Ports
49152 -> 65535 - Dynamic and/or Private Ports
Most implementations use ephemeral port numbers between 1024 and 5000
(solaris is an exception: it uses ports > 32768).
- Up to date official list of ports (IANA):
http://www.iana.org/assignments/port-numbers
...............................................................................
^ TOP ^
8. Fragmentation
================
Terminology note: "IP datagram (dg)" is the unit of end-to-end transmission
at the IP layer (before fragmentation and reassembly).
(TCP/IP Illustrated, "packet" is the unit of data passed between the IP and
Vol.1-W.R.Stevens ) link layers. A pkt can be a complete IP dg or a fragment
of an IP dg.
- When an IP dg traverses a medium that has a MTU smaller than the IP dg size,
then it will be broken into fragments (by the sending host or intermediate
router) that fit into the link layer's frames.
- MTUs: Ethernet -> 1500 bytes ; FDDI -> 4352 bytes
- Some characteristics of fragmentation:
+ Fragments are counted in units of 8 bytes (the smaller fragment is 8 bytes
because fragment offset field in ip hdr is 13 bits)
+ Maximum number of (8b) fragments: 8192 (65536 bytes)
+ Minimum usual fragment size: 128b (smaller fragments may be malicious).
+ Fragmented packets are only reassembled when they get to destination host.
+ If the DF (don't fragment) flag is set, the dg will not be fragmented,
and the router will issue an ICMP "destination unreachable - fragmentation
needed" (type 3 / code 4) packet to the originating host with the MTU of
the network needing fragmentation.
MTU path discovery: sending host issues an initial dg to destination host,
and if an ICMP error is returned with a smaller MTU,
it will package dgs in a way to avoid fragmentation.
+ Fragments can still be fragmented if they traverse a medium with an even
smaller MTU.
+ Some IP options are copied, but others remain with the first fragment only.
+ If one fragment is lost, the whole dg must be re-transmitted: as the
fragmentation can occur at any point of the route, the sending host has no
way of knowing how the pkt was fragmented. The pkt is kept for certain time
RFC 1122 recommends 60s-2min ; usually 30-60s ; Linux ~30s; Windows,
Solaris ~60s).
+ Then the timer expires an ICMP-11/1 (time-ex during fragment reassembly) msg
is issued, but ONLY if the zero offset fragment is not the missing one.
+ TCP has timeout and retransmission, but UDP doesn't.
+ Every internet module must be able to forward a datagram of 68 octets
without further fragmentation: 60b IP hdr + 8b (1 fragment)
+ ICMP msgs should be small enough so as not to require fragmentation.
- Whenever an IP dg is fragmented, new IP dgs are created with the following
characteristics:
+ All fragments must have the same IP header as the original one,
except for:
- MF: "More fragments" flag must be set if more fragments follow.
- Offset: offset of this particular fragment in the IP dg.
- Length: length of the newly created IP pkt.
- Header checksum.
- Options field (may be copied or not according to the "copied" bit)
- Header length
...............................................................................
^ TOP ^
9. Subnetting (CIDR, VLSM, ...)
===============================
- Solutions that were provided to slow IP Address Depletion:
1. Subnet Masking - RFC 950, RFC 1812
2. VLSM - Variable-Length Subnet Mask - RFC 1009
+ Provides the capability to include more than one subnet mask within a
class-based address, and the capability to subnet an already subnetted
network address, by using a portion of the host addr space as a subnet addr.
+ Can only be used when supported by the routing protocol (e.g. OSPF, EIGRP).
+ Advantages:
· Even more efficient use of IP addrs.
· Greater capability to use route summarization (more hierarchical levels)
3. Address Allocation for Private Internets - RFC 1918
4. NAT - Network Address Translation - RFC 1631
5. CIDR - Classless Inter-Domain Routing - RFC 1518, RFC 1519
+ See CIDR note
...............................................................................
^ TOP ^
10. ECN - Explicit Congestion Notification
==========================================
- RFC 3168
- ECN involves fields in both the IP and TCP hdrs:
+ IP hdr: Differentiated Services Byte:
bit 6 - (ECN) - Explicit Congestion Notification
bit 7 - (CE) - Congestion Experienced
+ TCP hdr: Reserved bits in byte 13:
bit 0 - (CWR) - Congestion Window Reduced
bit 1 - (ECE) - ECN-echo
- Mechanism:
IP-ECN IP-CE TCP-CWR TCP-ECE
SYN 0 0 1 1
SYN-ACK 0 0 0 1
ACK 0 1 0 0
No Congestion 0 1 0 0 (or)
1 0 0 0
Congestion (router) 1 1 0 0
Receiver Response 1 1 0 1
Sender Response 1 1 1 1
+ After this, the sender will reduce the sending buffer by half.
...............................................................................
^ TOP ^
100. OS ttl values
==================
(From: http://www.switch.ch/docs/ttl_info.html )
- Recommended default TTL for IP [45,105]: 6 (too small nowadays)
IP TIME TO LIVE PARAMETER
+--------------------+-------+---------+---------+
| OS Version |"safe" | tcp_ttl | udp_ttl |
+--------------------+-------+---------+---------+
AIX n 60 30
DEC Pathworks V5 n 30 30
HP/UX 9.0x n 30 30
HP/UX 10.01 y 64 64
Irix 5.3 y 64 64
Linux y 64 64
MacOS/MacTCP 2.0.x y 60 60
OS/2 TCP/IP 3.0 y 64 64
OSF/1 V3.2A n 60 30
Solaris 2.x y 255 255
SunOS 4.1.3/4.1.4 y 60 60
Ultrix V4.1/V4.2A n 60 30
VMS/Multinet y 64 64
VMS/TCPware y 60 64
VMS/Wollongong 1.1.1.1 n 128 30
VMS/UCX (latest rel.) y 128 128
MS WfW n 32 32
MS Windows 95 n 32 32
MS Windows NT n 32 32
A Look into the
Requirements for Internet Hosts Communication Layers RFC 1122, R.Braden, Oct 89):
The IP layer MUST provide a means for the transport layer to set the TTL
field of every datagram that is sent. When a fixed TTL value is used, it
MUST be configurable. The current suggested value will be published in the
"Assigned Numbers" and A fixed value must be at least big enough for
the Internet "diameter," i.e., the longest possible path. A reasonable
value is about twice the diameter, to allow for continued Internet growth
Assigned Numbers RFC 1700, J. Reynolds, J. Postel, October 1994): page 64:
Detailed information about TCP/IP stacks
AIX
TCP TTL is 60 but UDP has a too low TTL of 30. The TTL initial values
can be printed out and modified using the command "no". See the man page
for more instructions. Further measures might be required to make the
changes permanent.
DEC PATHWORKS V5 for DOS and Windows
TCP and UDP use too low TTLs of 30. These defaults can be modified in file
C:\PW\PWTCP.INI add line "IPTTL = 64"
HP/UX 9.0x
TCP and UDP use too low TTLs of 30. HP Support Center provided the
set_ttl tool to modify these defaults. HP/UX 10.0x TCP and UDP values
are set to 64.
Irix 5.3
TCP and UDP values are set to 64.
Linux
At least after V1.1.59 (and most probably before) Linux uses "safe"
values of 64 for both TCP and UDP default TTLs. As these values are
"hardcoded", occasional modifications have to be done deep in the
source - change the parameter sk->ip_ttl in file net/inet/af_inet.c to
whatever you think is appropriate for you. Some pointers to find the
position where sk->ip_ttl is set:
Linux V1.12.11: net/inet/af_inet.c line 695
Linux V1.3.45: net/inet/af_inet.c line 678
MacOS/MacTCP 2.0.x
TCP and UDP values are set to 60.
OS/2 TCP/IP 3.0
TCP and UDP values are set to 64.
OSF/1 V3.2A
TCP TTL is 60 but UDP has a too low TTL of 30. Modification of TCP/IP
stack parameters can be made with netconfig2.3
Solaris 2.x
All versions use a default value of 255 for both TCP and UDP.
SunOS 4.1.3/4
Since version 4.1.3, both TCP and UDP default TTL is set to 60. I have
no info about older releases, but these are obsolete anyhow. You can find
(or modify) the TTL values in
udp_ttl: in /usr/kvm/sys/netinet/in_proto.c
tcp_ttl: in /usr/kvm/sys/netinet/tcp_timer.h by
changing the parameter TCP_TTL
Ultrix
TCP TTL is 60 but UDP has a too low TTL of 30. Modification of TCP/IP
stack parameters can be made with netconfig2.3 VMS/Multinet
All recent versions use a TTL of 64 for TCP and UDP. Should a
modification of these parameters be required, it can be done as follows:
$ MULTINET SET/KERNEL TCP_TTL newvalue
$ MULTINET SET/KERNEL UDP_TTL newvalue
VMS/TCPware
TCPware for VMS (Alpha or VAX CPUs)
Default TTL = 60 for both TCP & UDP since at least TCPware 4.1-2A
If required for some reason, you can modify the values:
$ RUN TCPWARE:NETCU
NETCU> SET IPDEFAULTTTL default-time-to-live-hops
NETCU> EXIT
VMS/Wollongong Runtime Version 1.1.1.1
TCP TTL uses a safe value of 128, but UDP TTL is set to 32.
There is no way to change the defaults, but a new Runtime Version 2.5
is said to fix the problem (i.e. make the parameters configurable).
VMS/UCX
The latest version uses safe TTL values of 128 for TCP & UDP. No info
on older version available yet. TTL values can be modified, if needed, by
typing the command
$ UCX
UCX> set service/protocol=ip=time_to_live=64
MS Windows for Workgroups
Unsufficient TTL default values for both TCP and UDP. The defaults can
be modified in file SYSTEM.INI, MSTCP section, by adding a line:
DefaultTTL=64
Windows 95
The default TTL is 32 for both TCP and UDP. Modification:
- Double click on program 'regedit.exe' in the Windows95 root directory.
- Go to 'Hkey_Local_Machine\System\CurrentControlSet\Services\VxD\MSTCP.
- Select 'Edit' and in drop-down menu 'new'. Choose a data format and
enter parameter name and value in the appropriate format:
'binary value': DefaultTTL 01 00 00 00
'string format': DefaultTTL 64
Note that regedit adds quotes itself when using string format !
"Regedit-ophobe" people might alternativly have a look at the ttlfix
utility. Windows NT 3.51
The default TTL is 32 for both TCP and UDP. Modification:
- Double click on 'regedit32.exe' in the '\root\system32' directory.
- Go to:
'HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters'
- Change the "DefaultTTL" entry to: DefaultTTL REG_DWORD 64
Tools
-----
netconfig2.3:
available from: ftp://cs.ucsd.edu/pub/csl/Netconfig/netconfig2.3.tar.gz
With netconfig you can display and modify TCP/IP parameters in many Unix
implementations. It does not work for Solaris 2.x however. Be careful when
installing this tool, by default "make install" sets a "setuid root"
permission, which is probably not exactly what you want.
set_ttl:
An unsupported utility, provided by the HP Support Center, which lets
you change initial TTL values in HP/UX kernels. HP's set_ttl script is also
available directly from this server. ttlfix:
A small utility which automagicly changes Windows95 TTL defaults to
safe values. Available from:
ftp://ftp.active.ch/pub/internet/windows/ttlfix.zip
ttlfix requires vbrun300.zip for startup. Install it in directory
'\windows\system' if not yet there.
MAP Data Centre - February '96 - MAP WebMaster
Last Updated: 07/06/2004-14:50:08 - © Copyright 2004, Jess García