Hi Francis,
see below.
> => 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).
I was expecting that answer..:-)
>
> 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...
this is just to easy to say that. layer 4 classification will be used in the
campus backbone/high-end enterprise and with the current solution it is very
difficult to do it if you have any speed (we see 1GE links today and we will
see even 10 GE links very soon) so it is an issue if we want ipv6 hot "hit"
in the enterprise networks and campus networks...
if we dont solve the problem that IPv4 routers do today we are on the wrong
path...
One might argue that why not use intserv and treat the flowlabel as a
intserv flow and let the router map several flow into traffic classes of
aggregated traffic (DSCP classes) but then it is up to the flow label to
decide and that is as we know undefined....
>
> Have people thought about/What do people think about
> changing the length
> field
>
> => which one? The IPv6 header length field *is* useful and there is no
> free space.
I meant the Payload Length.... This is the whole point... I think you missed
my point.
I wanted a chance to classify on the trnasport header without having to have
a loop that first look into the first "next header" and then looks into the
senocd extension header "next header" pointer and then look into the next
one and in the next one...
This require a loop to run which makes it "practically" impsossible to
implement in an asic (which is the only way to go if you want speed and a
future proven roadmap for higher bandwidth with Moores law) it will let you
implement this in a processor based approach and because you will have a
loop consuming your pipiline stages in you network processor you will have a
VERY difficult task to solve!! (Eventhough I'm in favour of something
between a NP and a dedicated ASIC)
If we had a chance to mask out the offset where the transport header where
immediataly (without the need for a loop) then we can mask out the remaining
length that is the new "payload + transport header" and add it to the new
"IP header length" (that consists of basic header + extension headers)...
And then it is very easy to classify on layer 4.
I think that this would be a big improvement for ipv6.
>
> => I think nothing good of this. It is not the job of a
> router to look at
> inside packets (ESP will save us!)
People that implement this in hardware see this problem TODAY...
And of course if the packet is encrypted with an ESP then it is no use to
classify on L4 but then we could have a flag in the flow label field that "
signalled inband" that we have no way to do this, than we could aggregate
this in the router and block any QoS related policy that included layer for
instance...
But in most cases there sits a firewall at the same place where we have the
edge router and then the traffic comes unencrypted to the router and we
might want to classify the traffic into a DSCP based on layer 4 info (As a
side note: I have spoken to several operators that do exactly this way today
for IPv4
> And I would also like to define a mandatory limit on the
> length of the IP
> header incl extension headers.
>
> => 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.
Which is not so good if there are any speeds in an edge router...
>
> 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>
Of course I'm in favour of having the edge routers classify the packets.
But this was not the issue I raised here - I hope you understand what I
concerns?
-- 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 PROTECTED]
--------------------------------------------------------------------
