Re: reminder: clarification on tunnel entry-point address in "draft-ietf-v6ops-mech-v2-04.txt"

[Pekka Savola <pekkas@netcore.fi>]

On Fri, 13 Aug 2004, Alex Conta wrote:
> Alex Conta wrote:
> > This is a reminder of the usefulness of a clarification in 
> > "draft-ietf-v6ops-mech-v2-04.txt" in respect to the tunnel entry-point 
> > address being one of the encapsulator node's addresses.
> > 
> > Currently there seem to be an ambiguity regarding the IPv4 address of 
> > the tunnel entry-node in "draft-ietf-v6ops-v2-04.txt".
> > 
> > A clarification would be useful, stating that the tunnel entry-point 
> > address of an IPv6 in IPv4 tunnel must be an address that belongs to the 
> > encapsulator node.
> > 
> > Note that one of the consequences of configuring a tunnel with a tunnel 
> > entry point address which does not belong to the encapsulator is that 
> > ICMP messages referring to encapsulation errors, and thus destined to 
> > the encapsulator, may not reach the cause of the error, which is the 
> > encapsulator.

The proposition was to add language something like "the implementation
MUST verify that a manually the source address, if manually
configured, is an address of the node" to section 3.5.

With the editor and co-chair hats on, I have argued against this
because:

 1. the document is already past the IESG evaluation, with just one 
    discuss item to be cleared, and likely won't even need to be 
    revised.  We should not change it unless there are 
    significant problems.

 2. this is (IMHO) a user-interface issue, does not affect protocol 
    interoperability, and does not belong in the specification 
    (especially not in the uppercase, or mandated).

    That is, such a check could be used to mainly prevent the user
    from misconfiguring the source address ("shooting himself in
    the  foot").  Some implementations may want 
    to do that, some other might not: after all, it's the 
    administrator who's doing the configuration.  (I don't think the 
    IETF protocols typically provide mandatory provisions to prevent 
    misconfiguration by network operators/administrators.)

    On the other hand, I wouldn't see a big problem in adding a small 
    warning about this, as a reminder that the implementation may want 
    to consider this except I think it would be redundant information
    -- if it wasn't for the fact that the document is already
    basically out of the hands of this WG.

So, in summary, I think this is an implementation issue which doesn't
need to go to the spec, and because we're already pretty far in the
process, I'm arguing against it.

But I'm interested in hearing what the WG thinks about this.

Especially input from implementors would be appreciated (i.e., whether
you think adding that kind of specification would be useful or not).

(hats off)

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings