Will the packet be dropped when the number of hops equals to default TTL?
From my understanding, the default TTL represents the maximum number of hops allowed such that the packet may reach the host.
NTP Documentation Archive: ttl - This option is used only with broadcast server and manycast client modes. It specifies the time-to-live ttl to use on broadcast server and multicast server and the maximum ttl for the expanding ring search with manycast client packets
However, it is also mentioned in some answers that the packet is discarded if the TTL is 0 and it will never reach the host. I'm wondering what would happen when the number of hops before the packet was consumed is exactly the same as TTL_DEFAULT (e.g. TTL_DEFAULT is 2 and there are 2 hops before the packet was consumed). Will the packet reach the host, or it will be discarded?
ip ipv4 ipv6 ntp
New contributor
add a comment |
From my understanding, the default TTL represents the maximum number of hops allowed such that the packet may reach the host.
NTP Documentation Archive: ttl - This option is used only with broadcast server and manycast client modes. It specifies the time-to-live ttl to use on broadcast server and multicast server and the maximum ttl for the expanding ring search with manycast client packets
However, it is also mentioned in some answers that the packet is discarded if the TTL is 0 and it will never reach the host. I'm wondering what would happen when the number of hops before the packet was consumed is exactly the same as TTL_DEFAULT (e.g. TTL_DEFAULT is 2 and there are 2 hops before the packet was consumed). Will the packet reach the host, or it will be discarded?
ip ipv4 ipv6 ntp
New contributor
add a comment |
From my understanding, the default TTL represents the maximum number of hops allowed such that the packet may reach the host.
NTP Documentation Archive: ttl - This option is used only with broadcast server and manycast client modes. It specifies the time-to-live ttl to use on broadcast server and multicast server and the maximum ttl for the expanding ring search with manycast client packets
However, it is also mentioned in some answers that the packet is discarded if the TTL is 0 and it will never reach the host. I'm wondering what would happen when the number of hops before the packet was consumed is exactly the same as TTL_DEFAULT (e.g. TTL_DEFAULT is 2 and there are 2 hops before the packet was consumed). Will the packet reach the host, or it will be discarded?
ip ipv4 ipv6 ntp
New contributor
From my understanding, the default TTL represents the maximum number of hops allowed such that the packet may reach the host.
NTP Documentation Archive: ttl - This option is used only with broadcast server and manycast client modes. It specifies the time-to-live ttl to use on broadcast server and multicast server and the maximum ttl for the expanding ring search with manycast client packets
However, it is also mentioned in some answers that the packet is discarded if the TTL is 0 and it will never reach the host. I'm wondering what would happen when the number of hops before the packet was consumed is exactly the same as TTL_DEFAULT (e.g. TTL_DEFAULT is 2 and there are 2 hops before the packet was consumed). Will the packet reach the host, or it will be discarded?
ip ipv4 ipv6 ntp
ip ipv4 ipv6 ntp
New contributor
New contributor
edited 3 hours ago
M. Xu
New contributor
asked 4 hours ago
M. XuM. Xu
112
112
New contributor
New contributor
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
A TTL of 1 restricts a packet to the local network because a hop to another network will decrement the TTL to 0
, then the packet is discarded.
Every time a packet is processed, the TTL is supposed to be decremented, and then any packets with a TTL of 0
are discarded, but in practice no hosts do it that way. The original idea of TTL is actually Time to Live (in seconds), not a hop count, and each processing of the packet would decrement by the actual time used to process the packet, but the minimum decrement was 1
. The idea was to keep upper-layer protocols from receiving stale or duplicate data. This is explained in RFC 791, Internet Protocol, which is for IPv4:
Time to Live
The time to live is set by the sender to the maximum time the datagram
is allowed to be in the internet system. If the datagram is in the
internet system longer than the time to live, then the datagram must
be destroyed.
This field must be decreased at each point that the internet header is
processed to reflect the time spent processing the datagram. Even if
no local information is available on the time actually spent, the
field must be decremented by 1. The time is measured in units of
seconds (i.e. the value 1 means one second). Thus, the maximum time
to live is 255 seconds or 4.25 minutes. Since every module that
processes a datagram must decrease the TTL by at least one even if it
process the datagram in less than a second, the TTL must be thought of
only as an upper bound on the time a datagram may exist. The
intention is to cause undeliverable datagrams to be discarded, and to
bound the maximum datagram lifetime.
Some higher level reliable connection protocols are based on
assumptions that old duplicate datagrams will not arrive after a
certain time elapses. The TTL is a way for such protocols to have an
assurance that their assumption is met.
When IPv6 was created, the authors understood that TTL was not being used the way it was documented. For IPv6, the TTL was changed to Hop Limit to reflect how the TTL was actually being used. See RFC 2460
Hop Limit
8-bit unsigned integer. Decremented by 1 by each node that forwards
the packet. The packet is discarded if Hop Limit is decremented to
zero.
-and what routers are supposed to do when receiving an IPv6 packet:
if the IPv6 Hop Limit is less than or equal to 1 { send an ICMP Time
Exceeded -- Hop Limit Exceeded in Transit message to the Source
Address and discard the packet
}
-and where IPv6 recognizes that the IPv4 implementations of TTL were flawed:
8.2 Maximum Packet Lifetime
Unlike IPv4, IPv6 nodes are not required to enforce maximum packet
lifetime. That is the reason the IPv4 "Time to Live" field was renamed
"Hop Limit" in IPv6. In practice, very few, if any, IPv4
implementations conform to the requirement that they limit packet
lifetime, so this is not a change in practice. Any upper-layer
protocol that relies on the internet layer (whether IPv4 or IPv6) to
limit packet lifetime ought to be upgraded to provide its own
mechanisms for detecting and discarding obsolete packets.
I'm wondering what would happen when the number of hops before the
packet was consumed is exactly the same as TTL_DEFAULT (e.g.
TTL_DEFAULT is 2 and there are 2 hops before the packet was consumed).
Will the packet reach the host, or it will be discarded?
In practice, for an IPv4 packet with a TTL of 1
, the packet will reach and be processed by the destination on the same LAN. For a TTL of 2
, the packet will reach and be processed by a host one hop from the local LAN (second LAN). And so on.
That means if the destination of a packet with a TTL of 2
is two (router) hops from the local LAN, the second router will decrement the TTL on the packet to 0
and discard the packet before it reaches the destination (third) LAN.
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "496"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
noCode: true, onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
M. Xu is a new contributor. Be nice, and check out our Code of Conduct.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fnetworkengineering.stackexchange.com%2fquestions%2f56950%2fwill-the-packet-be-dropped-when-the-number-of-hops-equals-to-default-ttl%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
A TTL of 1 restricts a packet to the local network because a hop to another network will decrement the TTL to 0
, then the packet is discarded.
Every time a packet is processed, the TTL is supposed to be decremented, and then any packets with a TTL of 0
are discarded, but in practice no hosts do it that way. The original idea of TTL is actually Time to Live (in seconds), not a hop count, and each processing of the packet would decrement by the actual time used to process the packet, but the minimum decrement was 1
. The idea was to keep upper-layer protocols from receiving stale or duplicate data. This is explained in RFC 791, Internet Protocol, which is for IPv4:
Time to Live
The time to live is set by the sender to the maximum time the datagram
is allowed to be in the internet system. If the datagram is in the
internet system longer than the time to live, then the datagram must
be destroyed.
This field must be decreased at each point that the internet header is
processed to reflect the time spent processing the datagram. Even if
no local information is available on the time actually spent, the
field must be decremented by 1. The time is measured in units of
seconds (i.e. the value 1 means one second). Thus, the maximum time
to live is 255 seconds or 4.25 minutes. Since every module that
processes a datagram must decrease the TTL by at least one even if it
process the datagram in less than a second, the TTL must be thought of
only as an upper bound on the time a datagram may exist. The
intention is to cause undeliverable datagrams to be discarded, and to
bound the maximum datagram lifetime.
Some higher level reliable connection protocols are based on
assumptions that old duplicate datagrams will not arrive after a
certain time elapses. The TTL is a way for such protocols to have an
assurance that their assumption is met.
When IPv6 was created, the authors understood that TTL was not being used the way it was documented. For IPv6, the TTL was changed to Hop Limit to reflect how the TTL was actually being used. See RFC 2460
Hop Limit
8-bit unsigned integer. Decremented by 1 by each node that forwards
the packet. The packet is discarded if Hop Limit is decremented to
zero.
-and what routers are supposed to do when receiving an IPv6 packet:
if the IPv6 Hop Limit is less than or equal to 1 { send an ICMP Time
Exceeded -- Hop Limit Exceeded in Transit message to the Source
Address and discard the packet
}
-and where IPv6 recognizes that the IPv4 implementations of TTL were flawed:
8.2 Maximum Packet Lifetime
Unlike IPv4, IPv6 nodes are not required to enforce maximum packet
lifetime. That is the reason the IPv4 "Time to Live" field was renamed
"Hop Limit" in IPv6. In practice, very few, if any, IPv4
implementations conform to the requirement that they limit packet
lifetime, so this is not a change in practice. Any upper-layer
protocol that relies on the internet layer (whether IPv4 or IPv6) to
limit packet lifetime ought to be upgraded to provide its own
mechanisms for detecting and discarding obsolete packets.
I'm wondering what would happen when the number of hops before the
packet was consumed is exactly the same as TTL_DEFAULT (e.g.
TTL_DEFAULT is 2 and there are 2 hops before the packet was consumed).
Will the packet reach the host, or it will be discarded?
In practice, for an IPv4 packet with a TTL of 1
, the packet will reach and be processed by the destination on the same LAN. For a TTL of 2
, the packet will reach and be processed by a host one hop from the local LAN (second LAN). And so on.
That means if the destination of a packet with a TTL of 2
is two (router) hops from the local LAN, the second router will decrement the TTL on the packet to 0
and discard the packet before it reaches the destination (third) LAN.
add a comment |
A TTL of 1 restricts a packet to the local network because a hop to another network will decrement the TTL to 0
, then the packet is discarded.
Every time a packet is processed, the TTL is supposed to be decremented, and then any packets with a TTL of 0
are discarded, but in practice no hosts do it that way. The original idea of TTL is actually Time to Live (in seconds), not a hop count, and each processing of the packet would decrement by the actual time used to process the packet, but the minimum decrement was 1
. The idea was to keep upper-layer protocols from receiving stale or duplicate data. This is explained in RFC 791, Internet Protocol, which is for IPv4:
Time to Live
The time to live is set by the sender to the maximum time the datagram
is allowed to be in the internet system. If the datagram is in the
internet system longer than the time to live, then the datagram must
be destroyed.
This field must be decreased at each point that the internet header is
processed to reflect the time spent processing the datagram. Even if
no local information is available on the time actually spent, the
field must be decremented by 1. The time is measured in units of
seconds (i.e. the value 1 means one second). Thus, the maximum time
to live is 255 seconds or 4.25 minutes. Since every module that
processes a datagram must decrease the TTL by at least one even if it
process the datagram in less than a second, the TTL must be thought of
only as an upper bound on the time a datagram may exist. The
intention is to cause undeliverable datagrams to be discarded, and to
bound the maximum datagram lifetime.
Some higher level reliable connection protocols are based on
assumptions that old duplicate datagrams will not arrive after a
certain time elapses. The TTL is a way for such protocols to have an
assurance that their assumption is met.
When IPv6 was created, the authors understood that TTL was not being used the way it was documented. For IPv6, the TTL was changed to Hop Limit to reflect how the TTL was actually being used. See RFC 2460
Hop Limit
8-bit unsigned integer. Decremented by 1 by each node that forwards
the packet. The packet is discarded if Hop Limit is decremented to
zero.
-and what routers are supposed to do when receiving an IPv6 packet:
if the IPv6 Hop Limit is less than or equal to 1 { send an ICMP Time
Exceeded -- Hop Limit Exceeded in Transit message to the Source
Address and discard the packet
}
-and where IPv6 recognizes that the IPv4 implementations of TTL were flawed:
8.2 Maximum Packet Lifetime
Unlike IPv4, IPv6 nodes are not required to enforce maximum packet
lifetime. That is the reason the IPv4 "Time to Live" field was renamed
"Hop Limit" in IPv6. In practice, very few, if any, IPv4
implementations conform to the requirement that they limit packet
lifetime, so this is not a change in practice. Any upper-layer
protocol that relies on the internet layer (whether IPv4 or IPv6) to
limit packet lifetime ought to be upgraded to provide its own
mechanisms for detecting and discarding obsolete packets.
I'm wondering what would happen when the number of hops before the
packet was consumed is exactly the same as TTL_DEFAULT (e.g.
TTL_DEFAULT is 2 and there are 2 hops before the packet was consumed).
Will the packet reach the host, or it will be discarded?
In practice, for an IPv4 packet with a TTL of 1
, the packet will reach and be processed by the destination on the same LAN. For a TTL of 2
, the packet will reach and be processed by a host one hop from the local LAN (second LAN). And so on.
That means if the destination of a packet with a TTL of 2
is two (router) hops from the local LAN, the second router will decrement the TTL on the packet to 0
and discard the packet before it reaches the destination (third) LAN.
add a comment |
A TTL of 1 restricts a packet to the local network because a hop to another network will decrement the TTL to 0
, then the packet is discarded.
Every time a packet is processed, the TTL is supposed to be decremented, and then any packets with a TTL of 0
are discarded, but in practice no hosts do it that way. The original idea of TTL is actually Time to Live (in seconds), not a hop count, and each processing of the packet would decrement by the actual time used to process the packet, but the minimum decrement was 1
. The idea was to keep upper-layer protocols from receiving stale or duplicate data. This is explained in RFC 791, Internet Protocol, which is for IPv4:
Time to Live
The time to live is set by the sender to the maximum time the datagram
is allowed to be in the internet system. If the datagram is in the
internet system longer than the time to live, then the datagram must
be destroyed.
This field must be decreased at each point that the internet header is
processed to reflect the time spent processing the datagram. Even if
no local information is available on the time actually spent, the
field must be decremented by 1. The time is measured in units of
seconds (i.e. the value 1 means one second). Thus, the maximum time
to live is 255 seconds or 4.25 minutes. Since every module that
processes a datagram must decrease the TTL by at least one even if it
process the datagram in less than a second, the TTL must be thought of
only as an upper bound on the time a datagram may exist. The
intention is to cause undeliverable datagrams to be discarded, and to
bound the maximum datagram lifetime.
Some higher level reliable connection protocols are based on
assumptions that old duplicate datagrams will not arrive after a
certain time elapses. The TTL is a way for such protocols to have an
assurance that their assumption is met.
When IPv6 was created, the authors understood that TTL was not being used the way it was documented. For IPv6, the TTL was changed to Hop Limit to reflect how the TTL was actually being used. See RFC 2460
Hop Limit
8-bit unsigned integer. Decremented by 1 by each node that forwards
the packet. The packet is discarded if Hop Limit is decremented to
zero.
-and what routers are supposed to do when receiving an IPv6 packet:
if the IPv6 Hop Limit is less than or equal to 1 { send an ICMP Time
Exceeded -- Hop Limit Exceeded in Transit message to the Source
Address and discard the packet
}
-and where IPv6 recognizes that the IPv4 implementations of TTL were flawed:
8.2 Maximum Packet Lifetime
Unlike IPv4, IPv6 nodes are not required to enforce maximum packet
lifetime. That is the reason the IPv4 "Time to Live" field was renamed
"Hop Limit" in IPv6. In practice, very few, if any, IPv4
implementations conform to the requirement that they limit packet
lifetime, so this is not a change in practice. Any upper-layer
protocol that relies on the internet layer (whether IPv4 or IPv6) to
limit packet lifetime ought to be upgraded to provide its own
mechanisms for detecting and discarding obsolete packets.
I'm wondering what would happen when the number of hops before the
packet was consumed is exactly the same as TTL_DEFAULT (e.g.
TTL_DEFAULT is 2 and there are 2 hops before the packet was consumed).
Will the packet reach the host, or it will be discarded?
In practice, for an IPv4 packet with a TTL of 1
, the packet will reach and be processed by the destination on the same LAN. For a TTL of 2
, the packet will reach and be processed by a host one hop from the local LAN (second LAN). And so on.
That means if the destination of a packet with a TTL of 2
is two (router) hops from the local LAN, the second router will decrement the TTL on the packet to 0
and discard the packet before it reaches the destination (third) LAN.
A TTL of 1 restricts a packet to the local network because a hop to another network will decrement the TTL to 0
, then the packet is discarded.
Every time a packet is processed, the TTL is supposed to be decremented, and then any packets with a TTL of 0
are discarded, but in practice no hosts do it that way. The original idea of TTL is actually Time to Live (in seconds), not a hop count, and each processing of the packet would decrement by the actual time used to process the packet, but the minimum decrement was 1
. The idea was to keep upper-layer protocols from receiving stale or duplicate data. This is explained in RFC 791, Internet Protocol, which is for IPv4:
Time to Live
The time to live is set by the sender to the maximum time the datagram
is allowed to be in the internet system. If the datagram is in the
internet system longer than the time to live, then the datagram must
be destroyed.
This field must be decreased at each point that the internet header is
processed to reflect the time spent processing the datagram. Even if
no local information is available on the time actually spent, the
field must be decremented by 1. The time is measured in units of
seconds (i.e. the value 1 means one second). Thus, the maximum time
to live is 255 seconds or 4.25 minutes. Since every module that
processes a datagram must decrease the TTL by at least one even if it
process the datagram in less than a second, the TTL must be thought of
only as an upper bound on the time a datagram may exist. The
intention is to cause undeliverable datagrams to be discarded, and to
bound the maximum datagram lifetime.
Some higher level reliable connection protocols are based on
assumptions that old duplicate datagrams will not arrive after a
certain time elapses. The TTL is a way for such protocols to have an
assurance that their assumption is met.
When IPv6 was created, the authors understood that TTL was not being used the way it was documented. For IPv6, the TTL was changed to Hop Limit to reflect how the TTL was actually being used. See RFC 2460
Hop Limit
8-bit unsigned integer. Decremented by 1 by each node that forwards
the packet. The packet is discarded if Hop Limit is decremented to
zero.
-and what routers are supposed to do when receiving an IPv6 packet:
if the IPv6 Hop Limit is less than or equal to 1 { send an ICMP Time
Exceeded -- Hop Limit Exceeded in Transit message to the Source
Address and discard the packet
}
-and where IPv6 recognizes that the IPv4 implementations of TTL were flawed:
8.2 Maximum Packet Lifetime
Unlike IPv4, IPv6 nodes are not required to enforce maximum packet
lifetime. That is the reason the IPv4 "Time to Live" field was renamed
"Hop Limit" in IPv6. In practice, very few, if any, IPv4
implementations conform to the requirement that they limit packet
lifetime, so this is not a change in practice. Any upper-layer
protocol that relies on the internet layer (whether IPv4 or IPv6) to
limit packet lifetime ought to be upgraded to provide its own
mechanisms for detecting and discarding obsolete packets.
I'm wondering what would happen when the number of hops before the
packet was consumed is exactly the same as TTL_DEFAULT (e.g.
TTL_DEFAULT is 2 and there are 2 hops before the packet was consumed).
Will the packet reach the host, or it will be discarded?
In practice, for an IPv4 packet with a TTL of 1
, the packet will reach and be processed by the destination on the same LAN. For a TTL of 2
, the packet will reach and be processed by a host one hop from the local LAN (second LAN). And so on.
That means if the destination of a packet with a TTL of 2
is two (router) hops from the local LAN, the second router will decrement the TTL on the packet to 0
and discard the packet before it reaches the destination (third) LAN.
answered 1 hour ago
Ron Maupin♦Ron Maupin
65.2k1368122
65.2k1368122
add a comment |
add a comment |
M. Xu is a new contributor. Be nice, and check out our Code of Conduct.
M. Xu is a new contributor. Be nice, and check out our Code of Conduct.
M. Xu is a new contributor. Be nice, and check out our Code of Conduct.
M. Xu is a new contributor. Be nice, and check out our Code of Conduct.
Thanks for contributing an answer to Network Engineering Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fnetworkengineering.stackexchange.com%2fquestions%2f56950%2fwill-the-packet-be-dropped-when-the-number-of-hops-equals-to-default-ttl%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown