Hi All,
I've attached my comments on "IPv6 for Second and Third Generation Cellular Hosts" with responses from John Loughney. This came out of a more private discussion, but John and I both thought it would be useful to send this to the whole list. Margaret >From: [EMAIL PROTECTED] >Subject: RE: Preview of IPv6 for Second and Third Generation Cellular Hosts >Date: Fri, 26 Apr 2002 10:42:40 +0300 >Margaret, > >I've been creating a list of issues raised here & possible resolutions - >I hope you send this (or a version) to the list so I can answer there. > >Trimming the recipient list ... > > > General Comment: Document needs some text editing, particularly to > > eliminate run-on sentences and poorly formed paragraphs. > >Can do (I usually save this kind of editing for last ..) > > > Technical Comments: > > > > Section 1.1: > > > > This section should explicitly state that this document is not > > a standard and is not intended to modify the existing IPv6 > > standards. > >Will do. > > > Section 2.1: > > > > Path MTU discovery is a mechanism to save bandwidth, so it may > > be very desireable to implement for cellular hosts. > >Will add text about this, suggesting this with comments. > > > Section 2.4.1: > > > > Neighbor Solicitations and Neighbor Advertisements are not optional > > parts of Neighbor Discovery, and they should not be considered optional > > for cellular hosts. Cellular hosts should implement all of the > > required portions of ND, and use the state machine described in > > the ND specification. If you really believe that these parts of > > ND should be optional, then the ND spec should be re-visited. We > > should not just declare them optional here. > > > > The link layer sub option is link-specific, and it is fine that it > > does not apply to this type of link. > >This we need to add clarifying text as why we think using NA & NS may >be optional in some cases. Hopefully you can comment on this >after we write the text. > > > Section 2.5.1: > > > > DAD is not an optional part of Stateless Address Autoconfiguration, > > and it should not be considered optional for cellular hosts. > > If you really believe that DAD should be optional for some link > > types, we need to re-visit the Stateless Autoconfiguration spec. > > We should not just declare DAD to be optional here. > >I think we (the authors) need to do some thinking on this, as there >is the feeling that 2462 does not apply to the 3GPP network, but >I guess you feel strongly that it does. > > > Section 2.7.1: > > > > The document says: > > > > "To avoid any duplication in link-local addresses > > between the TE and the GGSN, the MT must always reject other > > suggested interface identifiers by the TE. This results in the TE > > always using the interface identifier suggested by the GGSN for its > > link-local address." > > > > What does this mean? I thought that laptops would be able > > to generate privacy addresses using randomly allocated identifiers. > > If not, we have a serious problem. Is this done to avoid the > > need for DAD? > >We may need to fix this text, I think it is not quite right. > > > Section 2.11 (and 2.13): > > > > The document says: > > > > "Cellular hosts should not support configured or automatic > > tunnels to avoid unnecessary tunneling over the air interface." > > > > Why would we want to make this recommendation? There may be > > good reasons for tunneling over the air interface. > >We need to fix the text, we intend to say that tunneling should be >avoided, as it may waste bandwidth - especially if there are other >mechanisms available. > > > Section 2.14: > > > > The document says: > > > > "The Dynamic Host Configuration Protocol for IPv6 [DHCPv6] may be > > used. DHCPv6 is not needed when IPv6 stateless > > autoconfiguration is > > used, and no other functions of DHCPv6 are used." > > > > I don't understand this paragraph. Can a cellular host use DHCP > > to get it address(es)? I would think DHCP would only be useful on > > a cellular host for other types of information. > >We will fix this, stating that DHCPv6 is not needed for stateless auto. >config, but may be useful for configuring othyer types of info. > >Thanks, >John -------------------------------------------------------------------- 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] --------------------------------------------------------------------
