RE: [Manet-dt] RE: SMF: Usage of IPv4 Identification field

[Teco Boot <[e-mail]>]

Brian,

I leave implementation details up to you. The only hint I can provide is the
number of fragments for a full IP datagram is typically low, as the maximum
IPv4 packet is 64KB and the minimum supported MTU is often mentioned as 576.
576 is the minimum size of IP datagram to be supported, so is not exactly
MTU (see RFC791).

Fragment order is an issue, a replay table is required. I think a bit table
with packets received with offsets to a sequence number base (as often used
in IPsec replay detection code) is not usable.

Teco


> -----Original Message-----
> From: Brian Adamson [mailto:[e-mail]]
> Sent: vrijdag 20 april 2007 14:51
> To: Teco Boot; [e-mail]
> Cc: 'manet'
> Subject: [Manet-dt] RE: SMF: Usage of IPv4 Identification field
> 
> Teco,
> 
> 
> This is a good comment.  I had also thought of this during the past
> couple of weeks.  The DPD filter I have implemented in the "nrlsmf"
> code now already supports variable length "packet identifier content"
> (on a per-flow basis) in order to handle the mix of possible use of
> IPv4 ID, the IPv6 SMF_DPD option header, IPSec, and the gateway
> "taggerID" option.
> 
> So, it should be possible to extend the code to concatenate the
> fragment offset (when applicable) with the IPv4 ID field as an
> extended packet identifier ... making a sort of effective 29-bit
> sequence number.
> 
> _BUT_ the challenge is that the 13 least signficant bits (the
> "Fragment Offset") do not incrementally increase in the manner of the
> other sequence numbers used (i.e, by one with each packet - the
> "fragment offset" increases as a function of the length of the
> fragments).
> 
> However, if one could assume that packets for a flow are fragmented
> to equal (i.e. MTU) size except for the last fragment, one could
> translate the "fragment offset" into a few bits of sequence space
> (i.e.  fragmentSequence = (fragmentOffset*8) / fragmentationSize)
> and the relatively low complexity/not-too-stateful approach of using
> a bit mask for sequence-based DPD could still be applied without
> requiring a very large window size ...  For the last fragment where
> the fragmentation size could not be inferred, since the MF flag is
> not set for this fragment, the implementation could assume that its
> "fragmentSequence" would be FRAGMENT_SEQ_MAX ...   If different
> fragmentation occurred in different parts of the network path as
> route changes occur, etc there might be some issue here, but that is
> not likely a frequent or sustained condition?
> 
> So, the question is ... what would a reasonable number of bits for
> the "fragmentSequence" space for an implementation to assume?  I
> would wager that it would not have to be very many, perhaps just 4?
> Thus extending the 16-bit IPv4 ID field to 20 bits for flows that are
> fragmented somewhere in the system.
> 
> Again, for various reasons, I don't think it is often a good policy
> to forward multicast fragments, particularly in a wireless network
> ... but this provision could be described in the SMF document if
> there is agreement among the working group ...
> 
> 
> 
> At 10:02 AM +0200 4/20/07, Teco Boot wrote:
> >I have a remark on using IPv4 DPD and support for fragmentation. I think
> it
> >is not that difficult to support fragmentation, we only have to extent
> the
> >DPD filter for Fragment Offset (and Protocol, to be compliant with
> RFC791).
> >Incorporating the Flags field (e.g. more fragments) is not needed but not
> >harmful either.
> >
> >The DPD filter should check on Source Address, Destination Address,
> >Protocol, Identification and Fragment Offset. Out of RFC791; header
> fields
> >not used by DPD are blanked:
> >
> >     0                   1                   2                   3
> >     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |       |       |               |                               |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |         Identification        |     |      Fragment Offset    |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |               |    Protocol   |                               |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |                       Source Address                          |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |                    Destination Address                        |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |                                               |               |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >
> >                     Example Internet Datagram Header
> >
> >                                Figure 4.
> >
> >IMHO updating DPD to RFC791 is important. Also for using it as remedy for
> >unicast routing loops as I suggested before.
> >
> >Cheers, Teco
> >
> >>  -----Original Message-----
> >>  From: Teco Boot [mailto:[e-mail]]
> >>  Sent: vrijdag 13 april 2007 11:36
> >>  To: '[e-mail]'
> >>  Subject: SMF: Usage of IPv4 Identification field
> >>
> >>  The SMF ID deviates from RFC791 for the Identification field.
> >>
> >>  791: "The originating protocol module of an internet datagram sets the
> >>  identification field to a value that must be unique for that source-
> >>  destination pair and protocol"
> >>
> >>  SMF: "In the case that resequencing is deemed necessary, it is
> RECOMMENDED
> >>  that sequence numbering be applied such that a different sequence
> number
> >>  space per <sourceAddress::destinationAddress> duple be used"
> >>
> >>  The difference is the protocol field. I see two options, modify SMF or
> add
> >>  text clarifying the deviation and analyze for consequences. Or are the
> >>  rules for Identification changed since 791?
> >>
> >>  Teco
> >
> >
> >
> >_______________________________________________
> >Manet-dt mailing list
> >[e-mail]
> >https://www1.ietf.org/mailman/listinfo/manet-dt
> 
> 
> --
> Brian
> __________________________________
> Brian Adamson
> <mailto:[e-mail]>



_______________________________________________
Manet-dt mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/manet-dt