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

[Brian Adamson <[e-mail]>]

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