Subject: [manet] SMF: DPD for IPv4

From: "Teco_Boot" <[email-masked]>
Date: Thu, 26 Jul 2007 14:28:50 +0200

Hi,

After reading back the SMF doc on IPv4 DPD, I think the text needs to be
more accurate what the exact DPD algorithm is.

I think the algorithm specification should be provided for all combinations
of ip_id, df flag, mf flag and fragment offset. Below a draft specification.

I also think we should try to be 100% compliant with RFC791. The consequence
is that the protocol field is part of the checked tuple, so it will become
<sourceAddress::destinationAddress::Protocol> 

I also think we should write a recommendation on usage of the ip_id field.
It would specify the need for using a sequenced value, including packets
marked for df. It would be a very short document, updating RFC791.
A big issue is the value zero. Is this value prohibited or not?

In the draft specification below, I included extended DPD, supporting
fragmentation.

Tagging (rewriting the ip_id) is a concern, mentioned by Fred Templin. We
could discuss using encapsulation. If we go for fixing ip_id usage, tagging
is a migration tool and is not used for nice behaving senders.

Teco.

+---------+----+----+----------------+-----------------------------------+
| ip_id   | df | mf | fragment offset| action                            |
+---------+----+----+----------------+-----------------------------------+
| zero    |  0 |  0 | zero           | invalid, do not forward (1)       |
| zero    |  0 |  1 | zero           | invalid, do not forward (1)       |
| zero    |  1 |  0 | zero           | tag and forward (4)               |
| zero    |  1 |  1 | zero           | invalid, do not forward (2)       |
| zero    |  0 |  0 | nonzero        | invalid, do not forward (1)       |
| zero    |  0 |  1 | nonzero        | invalid, do not forward (1)       |
| zero    |  1 |  0 | nonzero        | invalid, do not forward (3)       |
| zero    |  1 |  1 | nonzero        | invalid, do not forward (2,3)     |
| nonzero |  0 |  0 | zero           | DPD check and forward (5)         |
| nonzero |  0 |  1 | zero           | extended DPD check and forward (6)|
| nonzero |  1 |  0 | zero           | DPD check and forward (5)         |
| nonzero |  1 |  1 | zero           | invalid, do not forward (2)       |
| nonzero |  0 |  0 | nonzero        | extended DPD check and forward (6)|
| nonzero |  0 |  1 | nonzero        | extended DPD check and forward (6)|
| nonzero |  1 |  0 | nonzero        | invalid, do not forward (3)       |
| nonzero |  1 |  1 | nonzero        | invalid, do not forward (2,3)     |
+---------+----+----+----------------+-----------------------------------+

1: When the df flag is clear, the ip_id must be a non-zero value.
====> the question is, is a non-zero value really not allowed? It could also
be one of the 65536 values.

2: When the df flag is checked, the mf flag must be cleared.

3: When the df flag is checked, the fragment offset must be zero.
====> Not exactly specified in RFC791.

4: Tagging (resequencing) the ip_id should be performed once, on the edge
(ingress) of the MANET. As hosts could use a MANET router MANET interface to
connect, tagging on all MANET interfaces is required.

5: DPD algorithm uses <sourceAddress::destinationAddress::Protocol::ip_id>.

6: Extended DPD algorithm uses
<sourceAddress::destinationAddress::Protocol::ip_id::df::mf::FragmentOffset>
.

_______________________________________________
manet mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/manet

---

From: "Joe Macker" <[email-masked]>
Date: Thu, 26 Jul 2007 18:52:29 -0400

Teco:

These are some good notes. I believe we can consider adding the
fragmentation support as you outlined and will begin discussing this with
other contributors.

I believe the DF set (ID=0) rewriting case does not break anything and is
not used for IPSEC or fragmentation, but I will continue to discuss this
with others.  We know we have embedded kernels with this characteristic as
part of early deployments.

Thank you,
Joe

>-----Original Message-----
>From: Teco_Boot [mailto:[email-masked]] 
>Sent: Thursday, July 26, 2007 8:29 AM
>To: [email-masked]
>Subject: [manet] SMF: DPD for IPv4 
>
>Hi,
>
>After reading back the SMF doc on IPv4 DPD, I think the text 
>needs to be more accurate what the exact DPD algorithm is.
>
>I think the algorithm specification should be provided for all 
>combinations of ip_id, df flag, mf flag and fragment offset. 
>Below a draft specification.
>
>I also think we should try to be 100% compliant with RFC791. 
>The consequence is that the protocol field is part of the 
>checked tuple, so it will become 
>It would specify the need for using a sequenced value, 
>including packets marked for df. It would be a very short 
>document, updating RFC791.
>In the draft specification below, I included extended DPD, 
>supporting fragmentation.
>
>Tagging (rewriting the ip_id) is a concern, mentioned by Fred 
>Templin. We could discuss using encapsulation. If we go for 
>fixing ip_id usage, tagging is a migration tool and is not 
>used for nice behaving senders.
>
>Teco.
>
>
>
>====> the question is, is a non-zero value really not allowed? 
>It could also be one of the 65536 values.
>
>(ingress) of the MANET. As hosts could use a MANET router 
>MANET interface to connect, tagging on all MANET interfaces is 
>required.
>
>5: DPD algorithm uses 
><sourceAddress::destinationAddress::Protocol::ip_id>.
>

---

From: "Joe Macker" <[email-masked]>
Date: Mon, 30 Jul 2007 20:59:58 -0400

I have been personally convinced through discussions that fixing unexpected
ID field behavior, even in the limited non-IPSEC DF always zero case, is
poor practice in general. If kernels handle ID properly SMF should be able
to do passive IPv4 DPD reasonably well.  We should not expect incremental
increases either and that text will be changed. I am also tempted to add an
alternative IPv4 hashing DPD method similar to the IPv6 approach.

-Joe

>From: Joe Macker [mailto:[email-masked]] 
>Sent: Thursday, July 26, 2007 6:52 PM
>To: 'Teco_Boot'; [email-masked]
>Subject: RE: [manet] SMF: DPD for IPv4 
>
>Teco:
>
>These are some good notes. I believe we can consider adding 
>the fragmentation support as you outlined and will begin 
>discussing this with other contributors.
>
>I believe the DF set (ID=0) rewriting case does not break 
>anything and is not used for IPSEC or fragmentation, but I 
>will continue to discuss this with others.  We know we have 
>embedded kernels with this characteristic as part of early deployments.
>
>Thank you,
>Joe
>
>
>>After reading back the SMF doc on IPv4 DPD, I think the text needs to 
>>be more accurate what the exact DPD algorithm is.
>>
>>The consequence is that the protocol field is part of the checked 
>>tuple, so it will become <sourceAddress::destinationAddress::Protocol>
>>
>>It would specify the need for using a sequenced value, including 
>>packets marked for df. It would be a very short document, updating 
>>RFC791.
>Templin. 
>>We could discuss using encapsulation. If we go for fixing 
>ip_id usage, 
>>tagging is a migration tool and is not used for nice behaving senders.
>>
>>Teco.
>>
>>
>>
>>(ingress) of the MANET. As hosts could use a MANET router MANET 
>>interface to connect, tagging on all MANET interfaces is required.
>>
>>5: DPD algorithm uses

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 30 Jul 2007 18:07:45 -0700

Suits me.

Fred
[email-masked] 

> Sent: Monday, July 30, 2007 6:00 PM
> To: 'Joe Macker'; 'Teco_Boot'; [email-masked]
> >>tuple, so it will become 
> supporting 
> >>4: Tagging (resequencing) the ip_id should be performed 
> once, on the 
> >>edge