Subject: RE: Comments on zeroconf draft

From: "Karen E. Nielsen (AH/TED)" <[email-masked]>
Date: Wed, 8 Sep 2004 12:41:59 +0200

Hi Radhakrishnan, 
 
Thanks a lot for your comments.
 
Please find my comments inline.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Radhakrishnan Suryanarayanan
Sent: Wednesday, September 08, 2004 11:20 AM
To: [email-masked]
Cc: V6OPS WG; Pekka Savola
Subject: Comments on zeroconf draft

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.
 
[Karen E. Nielsen (AH/TED)]  I believe that you're right. The first paragraph is a reminiscent from version 00.

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..."
 
[Karen E. Nielsen (AH/TED)] , yes thanks. 

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?
 
[Karen E. Nielsen (AH/TED)] - The intended meaning of the paragraph is to say:

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

   globally routable (/128) IPv6 unicast address  to the end-hosts, which the

end-hosts can use for IPv6 communication through the zero-configuration tunnels."

Is that clearer ?

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?
 
[Karen E. Nielsen (AH/TED)]  NUD should be OK Radio power wise. The reason NUD is not explicitly referred to in Section 6.8, but unicast NS/NA exchanges are, is that by NUD one tends to understand the full mechanism described in Section 7.3 of RFC 2461, and this requires link-local multicast support - which we do not explicitly assume/require. Further there may be issues with NUD if it is required to be performed by the tunnel servers, as NUD on routers is susceptible to DoS attacks.

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.
 
[Karen E. Nielsen (AH/TED)] Thanks for your comments in that respect also.  

Narrowing the document to 3GPP as starting point has served its own purposes:

* 3GPP has severe timing requirements, wherefore this case has the highest priority.

* It has been claimed that the assisted tunnelling requirements wasn't adequate for 3GPP, wherefore it has been important to

see exactly how these requirements differs from the requirements of assisted-tunnelling - 

Now given that we have the requirements, this document could be used to decide:

* Initial: whether the 3GPP case is sufficiently different from assisted tunnelling for it to have its on life requirements wise

(and solution wise) - (if not the timing requirements alone makes it necessary for it to have its own life).

* Subsequently: if zeroconf tunneling as a concept is granted its own life, are there additional scenarios where this may be applicable.

Further are the additional requirements that should be served by zeroconf tunnelling so that it will be applicable to additional scenarios, which do not fit within the framework of assisted tunnelling.

Thanks. Karen

Thanks

Radhakrishnan

---

From: Pekka Savola <[email-masked]>
Date: Wed, 8 Sep 2004 14:14:25 +0300 (EEST)

My personal opinions only.

On Wed, 8 Sep 2004, Karen E. Nielsen (AH/TED) wrote:
> 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.
>  
[...]
> * Initial: whether the 3GPP case is sufficiently different from
> assisted tunnelling for it to have its on life requirements wise

I'd say, no, "zeroconf" requirements are common enough; some are
3GPP-specific, but many are not.  Then a logical approach would seem
to be have a "generic requirements" section (which would still be
sufficiently grounded in the operational scenarios), and sections on
specific requirements under different scenarios.
 
> necessary for it to have its own life).

IMHO, as this is just the requirements, the solutions could be the
same or not if everything was done under the label of "zeroconf", so I 
don't see this as a big factor.

> * Subsequently: if zeroconf tunneling as a concept is granted its
> own life, are there additional scenarios where this may be
> applicable.
> 
> Further are the additional requirements that should be served by
> zeroconf tunnelling so that it will be applicable to additional
> scenarios, which do not fit within the framework of assisted
> tunnelling.

IMHO, yes.

I can't see additional requirements which weren't there under the 
assisted tunneling.

Remember that assisted tunneling went out to provide requirements for
two different cases:  "zero-conf -like", and "controlled".  Now that
there is draft out on "zero-conf -like", it doesn't seem to be useful
to cover that under assisted tunneling, but just make it cover
"controlled".  Overlap won't do us any good..

-- 
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: Wed, 08 Sep 2004 19:40:04 +0530

Hi Karen,
   Please find my points inline:-
section 6.6
>=> 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?

>Is that clearer ?

=> Fairly yes. The meaning is end-host is going to get a IPv6 global address through the established tunnel.

>[Karen E. Nielsen (AH/TED)]  NUD should be OK Radio power wise. The reason NUD is not explicitly >referred to in Section 6.8, but unicast NS/NA exchanges are, is that by NUD one tends to understand the >full mechanism described in Section 7.3 of RFC 2461, and this requires link-local multicast support - >which we do not explicitly assume/require. Further there may be issues with NUD if it is required to be >performed by the tunnel servers, as NUD on routers is susceptible to DoS attacks.

=>Thats why i stated section 3.8 in RFC 2893. Cant we make it that explicit?
I am trying to see if we can make zeroconf fall in-line with whats stated in RFC 2893 which is about "Transition Mechanisms for IPv6 hosts and Routers".

Thanks
Radhakrishnan

---

From: "JORDI PALET MARTINEZ" <[email-masked]>
Date: Sun, 12 Sep 2004 15:49:04 +0200

Hi Pekka, all,

See my response in-line, below.

Regards,
Jordi

---- Original Message ----
From: "Pekka Savola" <[email-masked]>
To: "Karen E. Nielsen (AH/TED)" <[email-masked]>
Cc: "'Radhakrishnan Suryanarayanan'" <[email-masked]>;
<[email-masked]>; "V6OPS WG" <[email-masked]> Sent: Wednesday,
September 08, 2004 1:14 PM Subject: RE: Comments on zeroconf draft

>> [Karen E. Nielsen (AH/TED)] Thanks for your comments in that respect
>> also. [...] 
>> 

I've a similar view. I think it will be very useful to, once we have finalized the actual 3GPP specific requirements, complement or even rearrange the document in such way that we describe what of those requirements fit also in other scenarios (not just 3GPP). But we need to understand, as already explained before, that the main goal of the document is 3GPP. I mean, once 3GPP is done, now is more and more clear for all that it also provides a good set for a simple solution that could fit very well in other situations.

> "controlled".  Overlap won't do us any good..

This is a very good point. Actually zero-conf looks for a simple solution, which probably means not-controlled (assumed to be "self-controlled" because only works for the own-network-customers, read own-network as the ISP network, 3GPP network, enterprise network, etc.).

**********************************
Madrid 2003 Global IPv6 Summit
Presentations and videos on line at:
http://www.ipv6-es.com

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.