I wanted to verify I understand the models that are being used in the recommendation and ask about some parallels.
The draft recommends the GGSN assigning 64 bit prefixes to devices. For a single mobile device this amounts to creating a link scope with only one device on it. Would it be fair to say this is the source of the "you can ignore DAD" arguments? Additionally, if the device is going to have multiple identities (someone has used the Bluetooth Personal Area Network example) all of these will be effectively going through the device that has the gprs protocols, which means that it has taken on a sort of router function: Like a home network with a router hooked up over a dialup connection? Some questions: -is this similar to the idea of zero config home router set up (again the home network analogy). and can the solution proposed within be applied to that situation or can some common solution apply? -some elements of the gprs network were correctly considered a "given" for this recommendation. Is there any reasonable opportunity to engage in other, higher impact, longer term discussions about opportunities and applicability of moving to a v6 core network (perhaps even engage in dialog on the applicability of mobileipv6?). It seems to me that pdp contexts create kind of a "circuit" in an otherwise packet switched network and ipng expertise may be able to assist with information on how to apply ipv6 technology to get the desired effects as 3GPP attempts to move to an IP core network. -some of the optimizations (e.g. DAD removal) will presumably not be available in the case of the laptop connecting to a device where the device acts just as a provider of the link layer unless the laptop protocol stack is explicitly aware of the link technology? Is that true? -Would a way to avoid 3GPP appearing to be a special case to try to converge it with PPP in its approaches? That might mean that solutions that apply to ppp or gprs could be applied more generally to both and it might address comments like: > > 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. > As mentioned above, would it be fair to say stateless is only approximately stateless since prefixes are being statefully distributed and there is only one device using that prefix (or in more elaborate cases where there are multiple addresses or devices that a single device is managing the allocation within that prefix). Craig. -----Original Message----- From: Margaret Wasserman [mailto:[EMAIL PROTECTED]] Sent: April 26, 2002 8:12 AM To: [EMAIL PROTECTED] Subject: Review comments on IPv6 for Second and Third Generation Cellular Hosts 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] -------------------------------------------------------------------- -------------------------------------------------------------------- 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] --------------------------------------------------------------------
