Subject: Comments on zeroconf draft

From: Radhakrishnan Suryanarayanan <[email-masked]>
Date: Wed, 08 Sep 2004 14:50:22 +0530

Hi Juha,
  Here are my first set of comments:

section 6.3 
 "The tunnel protocol should allow the usage of native IPv6
 connectivity whenever such is available."

=> Isnt this paragraph is redundant? the 3rd paragraph in this section says it all.

section 6.5

" The discovery mechanism should rely on intrinsic services, read

   services already universally deployed, to the particular network

                                          ^^

   environment."

=> should be "...in a particular environment."

  "It should not require the addition of additional IP network ..."

                                         ^^^^^^^^^^  

=>  can be mentioned as "..addition of new IP network infrastructure..."

section 6.6

"

   The tunnel protocol must allow for the assignment of at least one

   globally routable (/128) IPv6 unicast address to use for tunneled

   IPv6 connectivity over the link provided by the Zero-Configuration

   Tunneling mechanism.

"

=> not very clear about the meaning of this paragraph. i guess it means that tunnel protocol gets a global IPv6 address before establishing a tunnel link for IPv6 connectivity. am i right?

section 6.8

=> does NUD (in section 3.8 in RFC 2893) helps? or does it help NOT having it for sake of saving Radio power?

Apart from this as i had already mentioned in my previous mails about a thought of expanding the applicability of this document beyond 3GPP. Maybe this is for the WG chair to decide.

Thanks

Radhakrishnan

---

From: Radhakrishnan Suryanarayanan <[email-masked]>
Date: Thu, 09 Sep 2004 14:38:23 +0530

Hi Karen,
> > > - plus keep alive messages
> >
> > .. which the client may choose not to send.
>
> Yes, but, quote:
> "but [the client] should then expect that the tunnel may be
>    disconnected at any time by the ISP and be prepared to restart the
>    set-up phase"
I dont think its hard to convince the authors of assisted tunneling draft to
change the "SHOULD to "MAY". In 3GPP networks, the ISP can always switch off
the keepalive messages & then
 the question of tearing down of a tunnel from ISP might not as well happen
at all.

> >
> > > - plus IPv6 dns registration by server side
> >
> > .. which is practically an implementation issue at the server side,
> > because the protocol is explicitly not required to support this.
> >
>
> Yes, that is what is being said (:-) But if you think about it
> this puts requirements on the tunnel protocol.
> As a minimum the server must be able to ascertain when a certain node
> (identified by something - the IPv4-address ?) is reachable and
> not-reachable at a certain IPv6-address.

IMHO, this is not a problem. Please see the quote below
" If stable prefix delegation is done, it is expected that the DNS
   delegation of the associated reverse DNS zone will be also stable and
   thus can be performed out of band, so there is no requirement to
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   perform this delegation at the tunnel set-up time."
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

> The authors of assisted-tunnelling have only thought about stateful
> mechs, I think.
Have the authors of zeroconf requirements have any stateless mech in mind?
I feel that  every tunnel server WILL have to maintain a min. set of client
parameters implicitly making it stateful.