Subject: Re: RFC 2529 (6over4)

From: Sowmini Varadhan <[email-masked]>
Date: Fri, 6 Aug 1999 12:51:48 -0400 (EDT)

>From [email-masked] Fri Aug  6 12:28:08 1999
>
>About DF: We tend not to put rationales in RFCs, and I would
>have to go back into some ancient archives to find the
>discussion on this. 

It would be nice to cross-reference the above documents if possible,
for the benefit of folks such as myself.

> I think the point is that since we cannot
>rely on IPv4 MTU discovery being deployed everywhere, setting
>DF would in some circumstances *guarantee* the loss of all
>6over4 packets and this would be very hard to diagnose
>operationally.

But that's precisely my point.  Yes, I agree that  the DF bit can cause 
a hard-to-diagnose scenario and therefore SHOULD NOT (as defined in RFC 2119) 
be set under most commonly occurring cases ; but I'm having a hard time 
seeing why it should never be set either (i.e. RFC 2119's MUST NOT)

>Can you come up with a case where setting DF would be a good
>thing to do?

Maybe I can't come up with that special case for DF today due 
to a lack of vision on my part.  However, my inability to come
up with a case for DF does not conclusively establish why 
the DF is to be outlawed. Which is why I feel it's a SHOULD NOT. Yes?

--Sowmini
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Cyndi Jung <[email-masked]>
Date: Fri, 06 Aug 1999 11:48:59 -0700

I really think that the black hole caused by an IPv4 segment of
the path with a smaller MTU than ethernet would be a major reason
to make the use of DF a MUST NOT.

Cyndi

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 06 Aug 1999 16:14:43 -0500

Sowmini,

Your argument is exactly what leads me to the MUST NOT conclusion.
Because it may cause very hard problems, don't do it. SHOULD NOT
leaves the door open to implementors to do the wrong thing.

   Brian