Re: Comments on zeroconf draft

[Radhakrishnan Suryanarayanan <rkrishnan.s@samsung.com>]

----- Original Message ----- 
From: "Karen E. Nielsen (AH/TED)" <karen.e.nielsen@ericsson.com>
To: "'Radhakrishnan Suryanarayanan'" <rkrishnan.s@samsung.com>; "'Pekka
Savola'" <pekkas@netcore.fi>
Cc: <juha.wiljakka@nokia.com>; "'Soininen Jonne (Nokia-NET/Helsinki)'"
<jonne.soininen@nokia.com>; "V6OPS WG" <v6ops@ops.ietf.org>
Sent: Thursday, September 09, 2004 3:26 PM
Subject: RE: Comments on zeroconf draft


> 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 ?
definitely i think we should think of communication initiation from both
sides.

>
> BR, Karen
>
>