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

[Alex Conta <aconta@txc.com>]

All,

Apologies for not bringing this up earlier on the WG list. The reason is 
that I noticed  this (see bellow) incidentally: it was not part of 
activity in the WG or IESG.

So I spoke about it with Erik N. and Pekka S. informally in San Diego. 
The message bellow was a reminder of the conversation.

What seemed to me to be a minor editorial correction solving a much 
bigger potential technical problem, has evolved in a debate, and both 
Pekka, and Erik asked me to bring this to the list, for both technical 
and procedural reasons. So please see bellow my original message.

Regards,
Alex


Alex Conta wrote:

> Hi Pekka,
>
> 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.
>
> Regards,
> Alex Conta

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