RE: Comments on zeroconf draft

["Karen E. Nielsen (AH/TED)" <karen.e.nielsen@ericsson.com>]

Hi Radhakrisnan,

> 
> 
> Hi karen,
>   I have some doubts. Can you clarify this point?
> The quote from the zerconf draft :
> "
>    Tunnel state here is considered to be any parameter kept by the
> 
>    server per client and without which the server is unable 
> to serve the
> 
>    client (receive packets from/send packets to).
> 
> "
> Isnt the client's/end-node's v6address reachability using the v6-in-v4
> tunnel itself a parameter maintained at the tunnel server? If so, then
> doesnt that itself means a tunnel state?
> 

If the mechanism is stateless, the v6 address of the clients need not be maintained
at the server. I think you know that - but I just want to be absolutely clear.

Goal 6.8 is there first and foremost to allow for NUD like mechanism to be performed by the
tunnel clients so that they, if need arises, can ascertain the 
reachability of their tunnel servers as
well as the reachability of peers in the direct tunnelling situation.

I can see that this should be clarified in the draft.

IF a Tunnel Server performs a NUD like mech on the clients it serves,
it must of course maintain reachability state as you describe.

Normally last hops routers performs NUD so that they can send ICMPs
back to origin to notify of black holes/unreachability. 
Personally I am not sure that this is a MUST requirement on the Tunnel Servers. I have 
actually thought that we could avoid this, especially since we have no explicit
goals as to the nodes being registered as reachable in the DNS using the Ipv6 address - wherefore
we are first and foremost looking to support the situation where communication
is initiated by the tunnel clients and not from the outside.

What do you think ?

BR, Karen