Hi Vishwas,
Maybe I am misunderstanding you, but I do not see the problem here. I
will try to explain how two different extension headers can be defined
without conflicting with a payload protocol type.
Imagine the GIEH has been allocated the IP protocol value of 144. Let's
also imagine that two new extension headers are defined using the GIEH.
The first header is allocated the specific type 6 and the second is
allocated the specific type 21. A TCP packet containing both these
headers will look like this
V= Version
NH= Next Header
HEL= Hdr Ext Len
ST= Specific Type
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V=6 | Traffic Class | Flow Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Length | NH=144 | Hop Limit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Source Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Destination Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NH=144 | HEL=5 | ST=8 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
. .
. 45 bytes of type 6 extension header specific data .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NH=6 | HEL=3 | ST=21 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
. .
. 29 bytes of type 21 extension header specific data .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TCP Header |
. .
. .
Do you see any problems with this?
Cheers
Suresh
On 10-04-26 07:51 PM, Vishwas Manral wrote:
Hi Suresh,
If you read the mail below (which I sent earlier in the day) this is
what I had said too. Just reserving values will not do, we need to
also define the structure otherwise it will not work.
i.e. An unknown extension header will have a known "Next Header" value but
an unknown "Specific Type" inside the GIEH and an unknown upper layer
protocol will have an unknown "Next Header" value.
This need not be the case. What if two new headers are defined. Also
if it is a payload how do we make sure the payload first byte does not
match a known "Next header" field.
I think the first case you need to define is some values of extension
headers (x to y). That will solve all your issues.
Thanks,
Vishwas
On Mon, Apr 26, 2010 at 4:24 PM, Suresh Krishnan
<suresh.krish...@ericsson.com> wrote:
Hi Vishwas,
On 10-04-26 05:13 PM, Vishwas Manral wrote:
Hi Stig,
I can agree that it's good to check demand, but I think it is good to
do the "future proofing" anyway. Things can then be implemented today
and work correctly (as in ignoring unknown headers and still finding
the transport) if new headers are introduced later.
An alternative approach could perhaps be to set aside a small range of
protocol values for future extension headers?
I do not think it is an alternative approach. The values tell its an
extension header (and are required look at my previous mail) and
follows the format defined, but the structure still needs to be
defined.
I think Stig means reserving a few IP protocol values for extension headers.
It is certainly an alternative approach (the scheme proposed in the draft
uses only one protocol number and demultiplexes extension headers based on
the "Specific Type" field)
Thanks
Suresh
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
