Bug #4223
closed
NDNLPv2: NextHopFaceId should not be allowed with Nack
100%
Description
In NDNLPv2, the appearance of NextHopFaceId field is currently defined as:
NextHopFaceId header field is permitted only on an LpPacket carrying an Interest, from an application to the forwarder.
Since a Nack is encoded as an Interest with a Nack header, it is an LpPacket carrying an Interest, and therefore the above definition allows the NextHopFaceId to appear on a Nack. However, a Nack is a hop-by-hop message, so it makes little sense to "forward" a Nack. Thus, NextHopFaceId should be forbidden on an LpPacket that has a Nack field.
Updated by Junxiao Shi over 7 years ago
Given Nack is an optional feature and Nack field has a non-critial TLV-TYPE Number, forbidding NextHopFaceId on Nacks can only be enforced if the node supports both Nack and consumer-controlled forwarding features. If a node does not support Nack feature, it would still accept NextHopFaceId as if it's on an Interest.
Thus, I suggest adding the rule as a "SHOULD" rather than a "MUST":
When NextHopFaceId appears on an LpPacket that has a Nack header field, the packet SHOULD be dropped.
NFD implementation already conforms to this rule.
Updated by Junxiao Shi over 7 years ago
- Blocks Bug #4224: DummyClientFace: NextHopFaceId handling differs from NFD added
Updated by Junxiao Shi about 7 years ago
20170807 NFD call approves this change.
Updated by Junxiao Shi about 7 years ago
- Status changed from New to Resolved
- Assignee set to Junxiao Shi
- % Done changed from 0 to 100
This is updated in NDNLPv2 rev16 along with other minor changes.