> The draft recommends the GGSN assigning 64 bit prefixes to > devices.
Just to avoid confusion, the draft itself doesn't recommend it but the prefix assignment is in the 3GPP specs. > 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? Not sure if I understand what you mean. The laptop/device and GGSN need link-locals and these can be ensured not to be duplicates by using e.g. PPP in the laptop case (interface id configuration option). Maybe that's what you meant anyway. The device is then assigned a (global) prefix by the GGSN on which only that device configures addresses. It's just like a router and a host connected over a PPP link where the router delegates a /64 prefix to the host (i.e. router does not configure addresses on the prefix). DAD would not be necessary in this particular case and its suppression would be a useful optimisation. Note that the GGSN will reply to NS for NUD. > 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? It could be just a multi-link modem (all identities have their own /64) or it could be a router as you say. Clearly the router has advantages but not all devices will have this functionality. > > 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? I think the idea was to consider the non-router case first and then apply the appropriate router solution which will hopefully be an existing one. However not all devices will have this. > > -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. Now it is most important to get IPv6 in 3GPP to be inline with the IETF standards. The longer term architectural discussions relating to the internals of the 3GPP network is probably something that should be decided and done in 3GPP, where the detailed knowledge of the architecture is, with the help of the ipv6wg etc. However, since we're in the early stages of IPv6 in 3GPP it is too soon to talk about architecture evolution. > > -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? 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: I think that it's appropriate to look at this case as a PPP link where there is some form of RA-based prefix assignment/delegation. > 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). > Agreed, due to the point-to-point wireless link-layer and other considerations. More info on this in draft-ietf-ipv6-3gpp-recommend-02 /Karim -------------------------------------------------------------------- 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] --------------------------------------------------------------------
