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

[Erik Nordmark <Erik.Nordmark@sun.com>]

> Problem 3
> Section 3.5 IPv4 Header Construction
> 
>   Following Text introduces protocol and security problem.
> ------
>             Source Address:
> 
> 
>                  IPv4 address of outgoing interface of the encapsulator
>                  or an administratively specified address as described
>                  below.
> ------
> [...]
>
> Suggestion:
> Change Source Address text to the following text:
> 
> 
>           Source Address:
> 
> 
>                   IPv4 address of outgoing interface of the encapsulator
>                   or an administratively configured address of one of the
>                   encapsulator's node addresses.

I think it makes sense to do this minor clarification since the current
text can be read as the protocol allowing the source address to be
configured to be the IPv4 address assigned to some other node.
This clearly doesn't work for many reasons such as ICMPv4 errors wouldn't be
sent back to the encapsulator.

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.


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

  Erik