Subject: RE: RFC 2529 (6over4)

From: Richard Draves <[email-masked]>
Date: Tue, 10 Aug 1999 21:29:41 -0700

Actually, the more I think about it the more I think that 6over4 should not
specify or recommend any setting or clearing of the IPv4 DF bit. Just be
silent on the issue.

There are two ways in which an implementation might want to set the DF bit:

1. The v4 stack is doing v4 PMTU discovery but it is not affecting the
6over4 link MTU. So here the result is that instead of having v4
fragmentation occur in some router, it happens in the sending node.

It is easy to implement this first scenario. In fact if your v4 stack
routinely does PMTU discovery this might be the easiest implementation.

Note that it's not very useful from the point of view of 6over4, because the
6over4 v6 link will not know about the v4 PMTU. So it doesn't affect the
size of the v6 packets that get sent, it just affects where v4 fragmentation
happens.

2. The v4 PMTU discovery ends up affecting the 6over4 link MTU. This is
tricky to implement because it means the 6over4 link MTU isn't constant -
potentially you have a different link MTU for reaching each neighbor. The ND
spec doesn't allow for this, but I think it's possible to implement it.

Rich
--------------------------------------------------------------------
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: Brian E Carpenter <[email-masked]>
Date: Wed, 11 Aug 1999 09:00:33 -0500

Rich,

> spec doesn't allow for this, but I think it's possible to implement it.

I think you have re-discovered the reason for the MUST NOT. Unless
we know how to handle this case, we have a problem, don't we?

BTW a little historical research reveals that this MUST NOT
appeared in the draft between August and October 1998, but I 
have no email about it and there is nothing relevant in the
Chicago WG minutes. 

  Brian

---

From: Grenville Armitage <[email-masked]>
Date: Wed, 11 Aug 1999 10:31:50 -0400

> we know how to handle this case, we have a problem, don't we?

Seems to me that's the very definition of SHOULD NOT clauses. They're
the ones that generally ought not to be done, but if the implementors
are sufficiently clueful about the 'tricky' implementation consequences
then they can chose to do so. Inserting a MUST NOT just means that
clueful implementors who want to go that extra effort will be shouted
at for being non-compliant.

cheers,
gja

---

From: Jim Bound <[email-masked]>
Date: Thu, 12 Aug 1999 10:56:30 -0400

>at for being non-compliant.

This was the jist of Sowmini's first premise.  I agree with that then
and with the above.  Just make it a SHOULD NOT and lets move on here.

/jim