Subject: Re: RFC 2529 (6over4)

From: Sowmini Varadhan <[email-masked]>
Date: Fri, 6 Aug 1999 11:09:29 -0400 (EDT)

>From [email-masked] Fri Aug  6 10:24:17 1999
>
>> > If we all accept the premise that they should both be consistent, then the
>> > question becomes- "which spec needs to conform?". The answer to that
>> > probably depends on which is more widely implemented at the current time,
>> > I guess.
>
>Let's see, you're talking about an inconsistency of debatable
>importance between an RFC at PS status and an *expired* internet
>draft; have I got it right?  Let me think about that for a
>millisecond.
>
>I've searched RFC's several different ways and can't find any other
>which specify a source/target link-layer address option.
>

I hope there was more substance to my mail than just that. 

I am well aware that source/target link-layer address options are not
defined in any RFC for configured tunnels. However, the fact remains
that there was once a draft defining this, and that configured tunnels do 
happen to be more widely implemented and tested than 6over4, so that
there is/was a possibility that the obsoleted link-layer option 
implementations were already established. Apparently it's not an issue..

>Can we move on now?

Sure. There are other issues, to which I am still waiting for a response- 
Having read RFC 2529, I'm still not convinced, for example 
that the setting of the DF bit is a MUST NOT. 
Also, there did not seem to be any discussion of the
scalability of V4 multicasting, considering its lack of deployment
(for which I am sure, there's a reason),  and the dependancies
between 6over4 (with all its virtues) and V4 multicasting.

Are we going to spend a few milliseconds in the RFC/mailing list
going over these details?

--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: Brian E Carpenter <[email-masked]>
Date: Fri, 06 Aug 1999 11:21:16 -0500

Sowmini,

This is an approved IETF proposed standard. That means that for
an implementor, there is no choice right now: what the RFC says is 
what you implement, right?

When we discuss the advancement of the standard, we should
indeed discuss whether to make changes in view of experience,
and your experience will be a key part of that.

Personally I agree with Matt, there is no reason to make
a change for consistency with Alex's old draft. I can't remember
why we right-justified the field; possibly it looked better from
an alignment point of view. Fundamentally it doesn't matter, so
why change it, absent a running-code reason to do so?

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. 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. A SHOULD NOT doesn't protect against this.

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

    Brian

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter (IAB Chair)
Program Director, Internet Standards & Technology, IBM Internet Div
On assignment for IBM at http://www.iCAIR.org 
Non-IBM email: [email-masked]
--------------------------------------------------------------------
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]
--------------------------------------------------------------------