[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

Follen, Stephen wrote: 
On Fri, 20 Aug 2004, Pekka Savola wrote:
[...]

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...


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.

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.


Attachment: smime.p7s
Description: S/MIME Cryptographic Signature