[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: RE:

no, it doesn't, for two reasons.

First, in a best effort network, it is invalid to presume that order will be preserved in the network.

Second, changing the identifier field in IPv4 from 16 bits to 10 and using the remaining bits to indicate something else is a change to the identifier field in IPv4. RFC 791 and RFC 1122 merely specify that the identifiers should be locally unique within a field of time, not that they have certain characteristics from which other functionality may be deduced.

I really not trying to be a pain here, but you really need to take this to a working group that does protocols, and specifically in this case, does changes to IPv4. v6ops can develop requirements for such a protocol if you like, but the protocol work needs to be done somewhere appropriate to the protocol.

On Aug 31, 2005, at 3:29 PM, Templin, Fred L wrote:

Fred,

What I suggested in my previous message was more dramatic
(and complicated) than what is really needed. If the tunnel
encapsulator simply defines for itself a coding for the
16-bit IPv4 Identification field such as the following:

    0                   1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Identification   |A|Segment #|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

then the requirements of RFC 791 (and the others) are observed
and there is no change to IPv4.

The bits encoded in the field would include a 10-bit ID, a
1-bit Auxilliary fragmentation flag and a 5-bit Segment number
for use by the tunnel decapsulator to reassemble a packet that
was segmented according to the link adaptation spec. There is
no need for a "Type-2 IPv4 fragmentation", there is no need to
set the Reserved fragmentation bit and there is no interaction
with ordinary IPv4 fragmentation/reassembly regardless of the
setting of the DF bit.

All that is needed is for the decapsulator to have a means for
receiving the 16-bit Identification field intact following IPv4
reassembly and a means for the encapsulator to discover whether
the decapsulator implements the link adaptation scheme.

One concern is that the actual Identifier is shrunk down to
10 bits instead of 16, meaning that the degree of packet
reordering in the network should be such that packets are
rarely mis-ordered by more than 1024 places. This is part of
the motivation for using a checksum to detect packet splicing
errors such as suggested by the link adapatation document.

Does this help address your concerns regarding changes to IPv4
and defining new protocols?

Fred
fred.l.templin@boeing.com


-----Original Message-----
From: Fred Baker [mailto:fred@cisco.com]
Sent: Tuesday, August 30, 2005 3:18 PM
To: Templin, Fred L
Cc: Lindqvist Erik Kurt; v6ops@ops.ietf.org
Subject: Re:

On Aug 29, 2005, at 7:30 PM, Templin, Fred L wrote:

So, can we call this a new (extension, mechanism, method, etc.)
instead of a new protocol and run it past the v6ops charter again?


If it uses IPv4 fields but re-interprets them in a way that
RFCs 791,
1122/3, 1812, 1349, and 2474 don't discuss, it is a change to
IPv4. I
would suggest discussing it in a working group that suggests
modifications to IPv4. If it's implemented in a header outside of
IPv4, it's a new protocol, and needs to be discussed in a WG that
deals with that.