Hi Margaret,
> (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. > (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." > > (snip) > > 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. 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? 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? > (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. Ok, let's remove the note! > (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? Correspondent node functionality is in draft-ietf-mobileip-ipv6-17.txt, section 8.1 and 9. Previous versions of our draft contained a more in-depth discussion of MIPv6 functionality. However, we received again a comment that we should remove the forward reference to the I-D. I do agree about the correspondent node functionality part, though. However, there's a couple of things we should observe: - In the current design, correspondent nodes do not need any special support unless they want to do Route Optimization. - The exact keyword for Route Optimization is being debated. My interpretation of the discussion is that SHOULD is winning. In any case, communications with e.g. old IPv6 nodes that do not yet support MIPv6 are always possible without any other problems than non-optimal routing. - Again, the forward reference... we could add a note describing that correspondent node functionality is something to be considered even if you don't use mobile node functionality, but of course it's hard to mandate an exact reference in a normative manner. Jari -------------------------------------------------------------------- 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] --------------------------------------------------------------------
