Subject: RE: Comments on zeroconf draft

From: "Karen E. Nielsen (AH/TED)" <[email-masked]>
Date: Thu, 9 Sep 2004 11:56:42 +0200

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

---

From: Pekka Savola <[email-masked]>
Date: Thu, 9 Sep 2004 14:53:57 +0300 (EEST)

On Thu, 9 Sep 2004, Karen E. Nielsen (AH/TED) wrote:
> 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.

This seems short-sighted to me, because the actual *advantage* of IPv6
is realized only when *incoming* connectivity is enabled (if it was
just about outbound connectivity, v4 would work as well).  If this
would imply that the communication between two nodes inside the 3GPP
network or communication originating from IPv6 internet and coming to
a 3GPP node could just silently fail.. this would seem to be very 
undesirable.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Radhakrishnan Suryanarayanan <[email-masked]>
Date: Thu, 09 Sep 2004 17:42:47 +0530

----- Original Message ----- 
From: "Karen E. Nielsen (AH/TED)" <[email-masked]>
To: "'Radhakrishnan Suryanarayanan'" <[email-masked]>; "'Pekka
Savola'" <[email-masked]>
Cc: <[email-masked]>; "'Soininen Jonne (Nokia-NET/Helsinki)'"
<[email-masked]>; "V6OPS WG" <[email-masked]>
Sent: Thursday, September 09, 2004 3:26 PM
Subject: RE: Comments on zeroconf draft

> is initiated by the tunnel clients and not from the outside.
definitely i think we should think of communication initiation from both
sides.