Hi Manav,
Thanks for the comments. Please find responses inline.
On 10-09-25 07:48 AM, Bhatia, Manav (Manav) wrote:
Hi,
I was reading draft-krishnan-ipv6-exthdr-08 and I think it does an incomplete
job of fixing IPv6's extension header treatment.
The only thing this draft addresses is the issue of an intermediary that wants to deep inspect the packet. The solution presented is that newer implementations should use the Generic IPv6 Extension Header (GIEH) which would internally carry the new extension header value. Devices that don't understand this new extension header value (one that's inside the GIEH) can look at the GIEH header and skip as many bytes as given in the Hdr Ext Len and continue with parsing the remaining packet.
If the above understanding is correct, then we really don't need GIEH! Why cant
the devices that want to parse the packet and which don't understand a given
extension header look at the Header length (specified in the extension header)
and skip those many bytes and get on to the remaining packet - how is GIEH
improving things?
Your understanding above is correct, but your conclusion does not
follow. The problem is that a new extension header may decide to have
the Header length at another location than the second byte or not have
one at all. The goal of the GIEH is to force all new extension headers
to have the Header length at a KNOWN location in order to skip over them
The reason I said this solution is incomplete is because it still doesn't solve
the problem of an end node receiving an IPv6 packet with some extension header
that it does not understand. What should it do with the packet? Discard it and
send an ICMP error back to the original source? If so, then how do you
incrementally deploy new extension headers in a network.
Yes. This (discard+ICMP) would be the expected behavior. I do not think
that extension headers should require any other behavior (please see
below). I see incremental deployment as requiring two consenting
end-points talking over an unaware network.
IMO, a complete solution is to standardize the new IPv6 extension headers that
are allocated in the future to the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | Hdr Options | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
. .
. Header Specific Data .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
We have added a 1 byte field called Hdr Options which should contain
information about how this extension header must be treated in case the
processing node does not recognize the extension header. Note that the
processing node can be either a device that's deep inspecting the packets
(firewall) or an end-node.
We can define the first two bits as follows:
00 - Skip and continue processing (used for incremental deployments)
01 - Silently discard the packet (could again be used for incremental
deployments)
10 - Discard the packet and send ICMP parameter problem message to the source
11 - Discard the packet and send an ICMP error back to the source only if the
destination is NOT a multicast address
This solution fixes the problem that GIEH is solving and additionally helps in incrementally introducing new extension headers in the network.
As specified in RFC2460, if this kind of behavior is required, I think
it is better to use Destination Options rather than an extension header.
Quoting straight from there.
" o If the desired action is for the destination node to discard
the packet and, only if the packet's Destination Address is not
a multicast address, send an ICMP Unrecognized Type message to
the packet's Source Address, then the information may be
encoded either as a separate header or as an option in the
Destination Options header whose Option Type has the value 11
in its highest-order two bits. The choice may depend on such
factors as which takes fewer octets, or which yields better
alignment or more efficient parsing.
o If any other action is desired, the information must be encoded
as an option in the Destination Options header whose ..."
Thanks
Suresh
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
