Re: 12 Problems with "draft-ietf-v6ops-mech-v2-04.txt" : was RE: Reminder: clarification....

[Alex Conta <aconta@txc.com>]

Erik Nordmark wrote:


> [...] 
> However, I don't think we need to repeat that the tunnel source address can not
> be an address not assigned to the node all over the document.

I agree.

Note though that Problem and Suggestions  1, 2, and some others, deal 
with the fact that with all the text that was removed from the RFC 2893, 
makes the text regarding configuring an address in Section 3.5 look like 
it comes from nowhere, without any supporting text anywhere else in the 
document. Earlier sections are supposed to create the support for 
Section 3.5., and so they are now incomplete, and the text in 3.5 looks 
like an orphan.

> > Problem 7:
> > Section 3.6 Decapsulation
> >
> > Black hole effect, in case one misconfigures the tunnel entrypoint, the 
> > tunnel exitpoint, or routing system instability causes source address 
> > oscillation.
> >
> > Node which was misconfigured has no way of finding out it did that.
> > Misconfiguration can happen at any end of the tunnel.
> >
> > Suggestion:
> > Change third paragraph to:
> >
> >     Packets for which the IPv4 source address does not match MUST be
> >     discarded and an ICMP message MUST be generated, with the error code
> >     ICMPv4 Protocol 41 Unreachable.
>
>
> I haven't read the followup emails on the list yet, but if this is
> essentially a form of source address filtering, the fact is that for
> ingress filtering there is no error message. So a MUST is definitely
> too strong - there are good reasons for not sending any error. A MAY might
> be appropriate [I have to read the rest of the messages on the list.]
>
> Sending protocol 41 unreachable seems like a likely source of confusion
> though so we shouldn't overload that.

If configuring the decapsulator is a form of "ingress filtering" that is 
optional, and separate from then tunnel configuration, I have no problem 
at all, and my suggestion does not apply.

However, if configuring the decapsulator is part of configuring the 
tunnel, as one of mechanisms of the tunnel, then the situation changes.

It is not different from configuring a PVC on ATM or configuring a PPP 
link.

If there is some problem configuring such a PVC, or PPP, there is some 
sort of notification telling you that.

A tunnel misconfiguration notification of some form, that propagates to 
the operator is I think necessary and helpful.

>   Erik

Regards,
Alex

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