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?
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.
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.
Cheers, Manav
--
Manav Bhatia,
IP Division, Alcatel-Lucent,
Bangalore - India
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
