Subject: [manet] some thoughts on DPD

From: Teco Boot <[email-masked]>
Date: Fri, 18 May 2007 10:57:57 +0200

All SMF and DPD fans, here some thoughts on DPD.

As DPD using hashing is to be supported more directly, we could re-evaluate
some issues:

-> We have to specify sent packets over a MANET are unique. Choices are
_SHOULD be unique_ or _MUST be unique_. We also have a choice on uniqueness
on the whole packet or the starting N octets. Hashing over a shorter string
would save CPU. I prefer lowering overhead, e.g. specifying the first 256
octets should guarantee uniqueness.

-> The hashing algorithm for IPv6 can be reused for IPv4. This provides
support for fragmented packets and RFC791 compliant packets (ID unique for
srce, dest and proto). I highly prefer RFC791-compliance. It takes some time
to adjust the SMF draft text, and some more time to adjust code. But let's
do it correctly. (don't forget blanking TTL before hashing;-)

-> I think IPv6 packets are NOT unique by nature. Typical examples for
duplicates are keep-alive and retransmits. Sending a sequence number, ID or
retransmit counter could be useful, but this is not mandatory. Or am I
missing something?
So making IPv6 packets unique could require marking. Is using the RFC2460
fragment option considered before? Aren't existing facilities preferred over
new mechanisms? Using this option would implement the same mechanism for
IPv4 and IPv6. IPv6 ID field is 32 bits and it should guarantee uniqueness,
otherwise an update of RFC2460 is needed. 
Some disadvantages: fragments with Fragment Offset on zero and M-flag on
zero are a little bit strange, and defragmentation code is touched. Also
hashing should be performed over a longer string, as (long) hop-by-hop
options, destination options and routing headers come in front of the
fragment header.
Taggers inserting a fragment option are not in line with RFC2460, but I
don't foresee problems.

-> I think DPD has a high level of acceptance by MANET unicast protocol
implementators, as it highly reduces negative effects in case of a routing
loop. This is another reason for careful specification of the mechanism. I
even think it should be part of the chartered WG work on defining a STD
unicast MANET protocol.

My 3 cents, Teco

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

---

From: "Velt, R. \(Ronald\) in 't" <[email-masked]>
Date: Fri, 18 May 2007 17:36:48 +0200

Teco, all,

> -----Original Message-----
> From: Teco Boot [mailto:[email-masked]] 
> Sent: vrijdag 18 mei 2007 10:58
> To: 'manet'
> Subject: [manet] some thoughts on DPD
> 
> As DPD using hashing is to be supported more directly, we 
> could re-evaluate some issues:
> 
> _SHOULD be unique_ or _MUST be unique_. We also have a choice 
> on uniqueness on the whole packet or the starting N octets. 
> Hashing over a shorter string would save CPU. I prefer 
> lowering overhead, e.g. specifying the first 256 octets 
> should guarantee uniqueness.
> 
> support for fragmented packets and RFC791 compliant packets 
> (ID unique for srce, dest and proto). I highly prefer 
> RFC791-compliance. It takes some time to adjust the SMF draft 
> text, and some more time to adjust code. But let's do it 
> correctly. (don't forget blanking TTL before hashing;-)

_And_ the Header Checksum...
_And_ the TOS-byte / DS field or TC field (IPv6), I guess. A duplicate
packet, having taken a different route than the original, may have been
remarked, while the original was left untouched or vice versa. One copy
may have had the ECN CE codepoint set, while the other has not.

> -> I think IPv6 packets are NOT unique by nature. Typical examples for

( =====8<--- snip --->8=====)

Regards,
Ronald

This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/disclaimer/email.html

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 18 May 2007 08:46:10 -0700

Hello Teco,

A few comments below...

> octets should guarantee uniqueness.
I thought that the problem was not in the manet, but in packets
arriving at a gateway for retransmission into the manet.  I agree
that we ought to specify uniqueness for all packets generated
within the manet.
> do it correctly. (don't forget blanking TTL before hashing;-)
For IPv4, I thought we had some consensus that the ip_id field was
good enough to verify uniqueness (per source).  What do you think?
> retransmit counter could be useful, but this is not mandatory. Or am I
Retransmissions are less common for broadcasts and multicasts, though... 
right?
> even think it should be part of the chartered WG work on defining a STD
Isn't it already chartered, essentially as a required part of SMF?

Regards,
Charlie P.

---

From: "Teco_Boot" <[email-masked]>
Date: Mon, 21 May 2007 13:43:09 +0200

Charles Perkins wrote:

>>>> Specification for uniqueness:
[Teco] 
I think it is better to specify it for both cases, e.g. end-to-end and on
MANET ingress boxes (taggers).
I think a need for changing packets in the network should be prevented.

>>>> DPD for IPv4:
[Teco] 
I think RFC791 shall take precedence over new ideas. So ip_id shall be
unique for srce, dest, proto and fragment offset as already specified in
RFC791. Why deviate from RFC791 when it is not needed?

>>>> IPv6 keep-alive and retransmits:
[Teco] 
I agree it is less common. But I think we have to support it.
PGM RDATA/NAK/NCF are examples (RFC3208). I didn't doublecheck for
duplicates, we can ask someone if needed. NORM (RFC3940) has sequence
numbers, so no problems there.

>>>> DPD for unicast MANET protocol:
[Teco] 
I am not aware of any activity making DPD part of a standards track RFC. I
suggest reusing SMF DPD mechanism for unicast forwarding. We could discuss
this at next IETF and decide it will be part of our chartered work.

---

From: "Teco_Boot" <[email-masked]>
Date: Mon, 21 May 2007 13:52:56 +0200

Ronald intVelt wrote:

>>>> hashing algorithm:
>>>> (don't forget blanking TTL before hashing;-)
[Teco] 
And we have to evaluate header options, e.g. updated routing headers.