Subject: RE: misconfiguring the tunnel source address [mech-v2-04]

From: "Follen, Stephen" <[email-masked]>
Date: Fri, 20 Aug 2004 14:27:43 -0400

>> The Enterasys implementation also does not check the tunnel source 
>> address at tunnel configuration time, primarily because to do so
would 
>> be overly restrictive to the admin in terms of order of
configuration; 
>> The admin is allowed the flexibility to configure the tunnel first
and 
>> then configure the IPv4 interface if (s)he wants to - but that's just

>> an implementation detail.
>
> This so called "flexibility" to configure a tunnel without the
existence a
> IPv4 interface, basically indicates that the box allows the creation
of a
> virtual point to point link, and route(s) that are using it, when
there is no
> physical connectivity to provide the basis for that link (and routes)
to exist.
>
> I do not see the advantage to the user, but can certainly see the
headaches...

The virtual point to point link's (the tunnel's) oper status is held
down until there is an interface configured with the source address,
also until there is a route to the remote v4 destination, etc.
I'm not trying to debate the fine points of a particular implementation
here; my point was only that these are implementation details.

>> 
>> IMHO this sort of stuff is not important enough to go into an RFC. 

> The spec promises a virtual point to point link between two nodes to
the user.
> Configuring the tunnel following the spec, and getting a tunnel that
does not
> work, is a spec bug.

There are lots of way one can follow most any spec and still not have
things work properly - misconfiguration is always possible.

>> It
>> seems obvious that if the tunnel source address does not exist on the

>> device, or if there is no route to the remote v4 destination, or ... 
>> the tunnel won't work.
>> 

> Specifications state often the obvious things to those who are
knowledgeable.
> That does not mean they should not contain what could be obvious to
some.

I agree, but specifications never do, and never can, state everything.
The question is where to draw the line. IETF specs, in general, do
assume some level of networking knowledge.
It's certainly not wrong to clearly state that the tunnel's source
address must an address configured on the device, I just don't think its
necessary to do so, especially at this late stage in the development of
this particular spec; others, of course, can have differing opinions.

---

From: Alex Conta <[email-masked]>
Date: Fri, 20 Aug 2004 15:20:36 -0400

Follen, Stephen wrote:

>>existence a IPv4 interface, basically indicates that the box 
>>allows the creation of avirtual point to point link, and
>>route(s) that are using it, when there is no physical connectivity 
>>to provide the basis for that link (and routes) to exist.
>> 
> down  

I thought so, 'cause otherwise would have been really a bug.

> until there is an interface configured with the source address,

...so you the implementation does check the source address...

> also until there is a route to the remote v4 destination, etc.

so, you must leave the tunnel creation dormant, and have a wakeup
on IPv4 interface, and/or route creation, with all the correlation and 
checks... well, if we talk complexity, honestly, this asynchronicity
is quite a bit more complex ...

> here; my point was only that these are implementation details.

They are implementation details indeed...

But as it turns out though, at a closer examination,
the implementation still checks, as you say, the source address, and 
that was the  focus of this discussion.

> [...]

keep in mind though that this is NOT misconfiguration according to
this spec, if the spec DOES NOT state that the tunnel source address 
MUST be one of the encapsulator's addresses.

That's the whole point...

If you put that in the perspective of a DRAFT standard, and replacing
an RFC, that didn't have that BUG, you have a completely different 
problem than just publishing a bogus PS RFC.

>[...]

---

From: Alex Conta <[email-masked]>
Date: Sat, 21 Aug 2004 10:01:59 -0400

resend:

Follen, Stephen wrote:

 >>existence a IPv4 interface, basically indicates that the box allows 
 >>the creation of a virtual point to point link, and

 > until there is an interface configured with the source address,

...so the implementation your refer to does check the source address...

 > here; my point was only that these are implementation details.

As it turns out, at a closer examination, this implementation still 
checks, as you say, the source address, and that was the focus
of these couple of messages.

 > things work properly - misconfiguration is always possible.

Keep in mind though that this is NOT misconfiguration according to
this spec, if the spec DOES NOT state that the tunnel source address 
MUST be one of the encapsulator's addresses.

If you put that in the perspective of a DRAFT standard, and replacing
an RFC, that didn't have that BUG, you have a completely different 
problem than just publishing a bogus or incomplete PS RFC.