Hi All,
I have several comments on this document, all offered as an
individual WG member (not as a WG co-chair).
Although I understand that the 3GPP would like us to complete
this document quickly, I still have some significant issues with
this document. I know that there is some resistance to any delay
at this point, but I believe that it is more important for us to
produce a correct, high-quality document that actually reflects
the consensus of the group, than it is to be responsive to an
externally imposed deadline.
My issues can be broken down into two categories:
- Technical/content issues
- Editorial comments
First, I'll deal with the technical/content issues:
(1) I think that this document should explicitly state, in the
introduction, that it is not a standard and is not intended to
modify or contradict any IPv6 standard documents. I thought that
we had agreed to something like this earlier.
(2) The document states:
"Additionally, due to special characteristics of the cellular link,
lower layer connectivity information should make it unnecessary to
track the reachability of the router. Therefore, while the host must
support Neighbor Solicitation and Advertisement messages, their use
is not necessary and the host may choose to not initiate them."
Although I understand the desire to supress NUD messages on
point-to-point cellular links, this isn't how/why this should
be done.
IPv6 hosts must include a full implementation of Neighbor Discovery,
including NUD with the full ND state machine, etc. Any compromise
on this effectively results in two different types of IPv6 hosts,
each with different behaviours/failure modes, etc. That is something
that we definitely want to avoid.
There is no magic (in 3GPP or any other network) that can
guarantee that another node is always reachable, but it is
certainly possible for other layers of the protocol stack
(outside of IP) to maintain information about reachability,
and to know, at a given time, that another node is reachable.
ND includes the ability for those other protocol layers to
provide advice to the NUD code to indicate that a remote host
is reachable (only when those layers have confirmed two-way
reachability), which results in the supression of NUD messages
when the network is operating properly. The other layers of
3GPP should provide this advice to ND.
In cases were the GGSN actually does become unreachable, NUD
messages will be sent. But, in fact that NUD actually _reduces_ the
amount of traffic that will sent over the air interface while the GGSN is
unreachable, so this is actually a good thing for 3GPP.
Instead of indicating that parts of ND are optional, or that
3GPP hosts may "choose to not" use them, we should be indicating
what layers of 3GPP should provide reachability advice to ND at
what points. If those other layers can confirm two-way reachability
on an ongoing basis, they can provide frequent advice that will
result in the supression of all NUD messages when things are
operating properly.
(3) The document states:
"This specification [RFC-2402] must be supported. The IPsec WG has
discussed the role of AH in the future, and it is possible that it
will be made optional in the future versions of the IPsec protocol
set. Implementers are recommended to take this in account."
I don't like the idea of writing a document today that tells
implementors that it is possible that something will be made
optional in the future. Today it is mandatory. Period.
(4) The document states:
"4. Mobility
For the purposes of this document, IP mobility is not relevant. When
Mobile IPv6 specification is approved, a future update to this
document may address these issues, as there may be some effects on
IPv6 hosts due to Mobile IP. The movement of cellular hosts within
3GPP networks is handled by link layer mechanisms."
There is a portion of mobility -- I believe that is is called the
"correspondent node option", or something like that -- that must be
implemented in all IPv6 hosts, in order to allow optimal routing
to mobile nodes that are away from their home networks. This document
should indicate that support for that feature is required.
Can one of the MIP folks help me here? What is it called, and where
is it defined?
Now, for the editorial issues:
(5) In section "1 Introduction", the only paragraph is not
properly laid out -- not clear if it is meant to be one or
two paragraphs.
(6) The document states:
"Cellular hosts should not support configured or
automatic tunnels to avoid unnecessary tunneling over the air
interface, unless there are no other mechanisms available. Tunneling
can lead to poor usage of available bandwidth. "
The "should not support...unless there are no other" construct
is somewhat confusing, since there probably isn't any way for
a host to know whether there are other mechanisms available.
Although I understand why tunneling should be avoided over the
air interface if possible, I don't understand why this is a host
implementation issue. Isn't this more of an issue for the
operators? If so, it probably doesn't belong in this document.
(7) As someone else mentioned, the following sentence is
similarly confusing:
"Multicast Listener Discovery [RFC-2710] may be supported, if the
cellular host is supporting applications that require the use of
multicast services."
(8) I also think that the following sentence is more advice for 3GPP
network operators, than it is specific to cellular hosts:
"Hence,
intermediate 6to4 routers should carry out 6to4 tunneling, instead
of cellular hosts."
There is an ongoing effort in the ngtrans WG to discuss transition
scenarios for 3GPP (run by Jonne Soininen), and it is expected that
that group will define what type of transition mechanisms are most
applicable to 3GPP networks. So, perhaps it is best to leave this
operator advice for that group?
(9) I don't think that you should put "Manyfolks" in the footers,
in the place of the author name. List the first author with et.al.
Or, better yet, switch to listing an editor in the footer and at
the top of the document, and list the authors in a section at the
end.
Margaret
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
