cfdef3b5
From: barmar@alum.mit.edu
In article
<680722e9-0fbe-4c16-b5d9-d20d0ddd87b3@y10g2000prg.googlegroups.com>,
Albert Manfredi wrote:
> On Nov 15, 4:26 pm, Martijn Lievaart wrote:
> > On Sun, 15 Nov 2009 20:02:47 +0000, Jorgen Grahn wrote:
> >
> > > People who know more will have to correct me, but I think you *do* have
> > > that functionality in IPv4. You have the IP options, and you can stick a
> > > header between the IP header and the UDP or TCP header (like IPSEC
> > > does). It's just less elegant and efficient (I think someone upthread
> > > mentioned that).
> >
> > There are tcp options and as a special case, the ipv6 header chaining is
> > used in ipv4 for ipsec, and for ipsec only.
>
> I think both responses are true, but I think the simple answer to the
> original post is that the "next header" field in IPv6 accomplishes
> also the same function as the "protocol" field of IPv4. And it even
> uses the same numerical values to denote the protocol that follows.
>
> So, if the IPv6 basic header is immediately followed by UDP, then the
> UDP protocol ID 17 (decimal).
The v6 next-header field accomplishes what's done in v4 by encapsulating
protocols within the data field of other protocols. The v6 designers
noticed that there was quite a bit of encapsulation going on, in
protocols like IP-in-IP, GRE, etc. This is inefficient, because lots of
redundant processing has to be done, but it's done this way because the
v4 designers never anticipated the way protocols would be layered.
The v6 designers had the advantage of this hindsight. As noted, it
accomplishes everything we already do with the protocol field, but also
uses the same mechanism to replace encapsulation.
--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE don't copy me on replies, I'll read them in the group ***
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
