Thanks Thomas (and the IESG) for the comments. Some responses inline:
>>RFC 3155 should be added to the normative refs in my >>opinion. I'm not opposed to keeping the non-normative >>ref to the 2.5/3G TCP issues draft that started me on >>this. Ok! >>2.4.1 says that the host must support receipt of >>Neighbor Solicitation and Advertisement messages. >>But 2.5.1 says "will not be sent or received" which might seem >>conflicting at least with respect to the receive part. Right. 2.4.1 and it's latest revs that have been discussed on the list is correct here. 2.5.1 should say "Duplicate Address Detection will not be initiated by the cellular host.". >>DAD for 3041 addresses? >>Will the router only have a link-local address on the link? >>If not, how to detect a 3041 conflicting with one of the routers >>addresses? Router will have only a link-local address on the link. >>2.12 - 3041 MAY be used. Do we want something stronger? Well, isn't the current keyword for 3041 essentially a MAY in the v6 standards? Note also that the cellular network privacy situation is not as bad as, say my fixed IP DSL situation. The prefixes change over time, as you turn off/on the device or go temporarily out of coverage. >>MLD: >> multicast services. There is no need for MLD if the host only >> supports the well-known (hard coded in IPv6 implementations) link >> local multicast addresses. MLD is not used for listening on such >> addresses. >>Only applies to all-nodes address (ff02::1). >>RFC2461 says that a node must join >>the solicited-node multicast address(es) on multicast-capable interface, >>and point-to-point interface are specifically treated as >> point-to-point - Neighbor Discovery handles such links just like >> multicast links. >> >>Thus per the letter of the specifications MLD must be implemented >>by cellular hosts. Discussion ongoing on the list though, see e.g. Brian's e-mail. >>This also effects the need to support RFC2711 (section 2.10). Yes. We could clarify the text in 2.10 to say that it is required if you do MLD. >>2.11 >> (IPv4 vs. IPv6). 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 bandwidth concern is a reason not to *use* tunneling, but >>the point about it being a last resort seems to say that it would >>be useful to implement this. However, the text "should bot support" >>seems to mean "should not implement". >>Same issue for section 2.13 on 6to4 tunneling. These have been, I believe, satisfactorily resolved after a discussion with Margaret: basically, we are letting the ngtrans design team to specify this, in the documents. >>2.15: and all useful hosts have at least a link-local address >>and a larger scope address. So why not say "must be supported" >>instead of qualifying it with a tautology? Ok! >>2.16 - add reference to RFC 3152. RFC 1886 talks about ip6.int >>thus the ip6.arpa document must be referenced. Sounds good. >>Section 3 - how about adding that future IPsec algoritms might be >>useful/supported in the future. >>Currently only DES, HMAC-MD5, and HMAC-SHA1 are listed. We actually had that at one point in time. We could add a note that some good algorithms are coming in the future. I fear that AES isn't an RFC yet. Don't want to reference I-Ds. >>The docuent is vague on key management. It basically doesn't say what >>will be used for key management, and that begs the question of what >>kind of interoperability will be achieved. >> >>If AKA is the solution, then this needs to be made more clear in the >>document. Isn't it the case that AKA is what the overall >>theme for 3GPP? >> >>What is needed is a clear statement on how interoperability with >>regards to key management will be obtained. If this is not actually >>known today, then the document should just say we haven't decided yet, >>but will decide down the road. All of the above is true, but then again this is an IP layer document and doesn't specify a complete system. Basically, I believe we are more or less equally vague with the IPv6 standards. In practise, the situation is likely the following: * IPsec in general will use IKE or its successors. * The IP multimedia system will use IPsec, but key itself via AKA-generated keys * Web, wap, etc. is likely to use TLS. I'm open to suggestions but I'm not sure exactly what we can say. Can we mandate key management and its interoperability in IPv6 standards? 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] --------------------------------------------------------------------
