Subject: Regarding the Options headers

From: "Thomas Eklund" <[email-masked]>
Date: Wed, 15 Nov 2000 14:00:34 +0100

Another comment on the extension header orders...

What we need is a more deterministic approach to build the daisy chain of
headers. Because we cant have the different flavours and it is very
difficult as it is when we have to parse all the extension headers to get to
the transport header (which is useful for layer 4 classification)...

This is no problem if you do it in a sw based router where you have all the
time in the world to parse your header but it becomes an issue when you
implement IPv6 in asic!!

Have people thought about/What do people think about changing the length
field and replacing it with a (IP) header length field (the basic header +
the extension headers) and have a mandatory payload length in the last
extension header (transport header + payload)? (one flag that tells if the
packet is decode with an ESP header where packet classification on layer 4
info is useless - of course:-)

This would really make it easier to mask out the offset in the basic header
towards the transport header (which simply would make up to the loss of the
protocol field that we had in IPv4) without having to have too wide packet
decoding (which becomes a real problem when you have to go over 300 bytes in
oc-768 speeds and above)

And I would also like to define a mandatory limit on the length of the IP
header incl extension headers.

What do people think?

-- thomas

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Francis Dupont <[email-masked]>
Date: Wed, 15 Nov 2000 14:55:10 +0100

In your previous mail you wrote:

   
=> I understand your concern but I have just replied to Robert Elz
a MUST for the layout of extension header chain would be too strong
then you must support any layout, including crazy/exotic.

   This is no problem if you do it in a sw based router where you have all the
   time in the world to parse your header

=> no, a software based router wants to be fast too and will just look at
the destination address (me/them) and the next header type (zero/non-zero).

   but it becomes an issue when you implement IPv6 in asic!!

=> just don't do layer 4 classification in a router?
Seriously I expect to avoid a IPv4-like situation where options are not
used because they are processed slowly then not used then...
   
   field

=> which one? The IPv6 header length field *is* useful and there is no
free space.

   and replacing it with a (IP) header length field (the basic header +
   
=> I think nothing good of this. It is not the job of a router to look at
inside packets (ESP will save us!)

=> (provocation mode on) use MPLS? (provocation mode off)

=> the maximum size of one extension header is 2048 ((255+1)*8) octets,
this is already far more than the minimal MTU (1280) then I expect nobody
will get a consensus for that.

   What do people think?
   
=> do the layer >= 4 classification at the edge and use DS byte, flow label,
... to mark packets. I believe this is the IntServ/DiffServ lesson: core
routers should route <dot>

Regards

[email-masked]

---

From: "Markku Savela" <[email-masked]>
Date: Wed, 15 Nov 2000 16:00:55 +0200

> -----Original Message-----
> From: EXT Thomas Eklund

> time in the world to parse your header but it becomes an

How about going with the original spirit of the Internet, that routers have
no business of snooping into packet any deeper than the IP header?

Lets keep it clean, and not break the layering!