> > (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.
>
>Yes, we had agreed this and we even had the note... until we were told
>that we shouldn't re-state the type of the document in the text.
In this case, the intended audience of the document primarily lies outside of the
IETF. Do you think that they will really understand the difference between our
different document types? My understanding is that the 3GPP wants this
document to have an RFC number ASAP, so that they can use it as a
normative reference in one of their standards... right?
> > (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."
> >
>Isn't this what we were trying to say? In 2.4. we state that ND
>is a mandatory part of IPv6. Then the text you quoted above
>was meant to say that lower layers do provide connectivity information,
>leading to supression of NUD messages. Or did you want more details
>as to exactly what layers, or the treatment of the error case?
The text from the document (above) clearly indicates that hosts may choose
not to initiate NS and NA messages. I read that to mean that a host may
choose _never_ to initiate these messages, even when NUD (or other parts
of ND) would require initiating these messages.
It would be much clearer to state that 3GPP nodes must inlcude a full
implementation of ND, including NUD, but that other parts of the 3GPP system
may provide advice to the NUD code which result in supression of NUD messages,
and site the section of the ND specification that indicates how such advice
is used.
Please note that the layers that provide advice to NUD about connectivity
need to be able to ensure two-way IP-level connectivity. If there are no
3GPP layers that can do that, occasional NUD traffic may result. NUD
only happens when there is traffic to send, and when there has been no
recent confirmation of two-way connectivity (from TCP, for example), so
it is not expected to generate much traffic.
>But I'm not sure I understand why NUD should be sent when the
>lower layers tell us that the GGSN is down -- the link is then
>down, and nothing gets through. Or did I miss something?
If the link is down, obviously no messages will be sent. But, what if the
link is up, but the GGSN is down? Or what if the GGSN is not forwarding
packets and/or responding at layer 3?
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]
--------------------------------------------------------------------
