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