Hesham Soliman wrote: > First of all, I think that connecting to the > Internet MUST be madated, not optional :)
I am glad we agree. > ... > => That's a bit inaccurate, there is a major difference > that is due to the BW contraints of the air link. > I see your points about size and memory, but it would > be good if we identify the parts related to size > and memory in which the draft deviates from IPv6 > standards and distinguish them from the BW and > l2-specific impacts. Let's not go there. Those of us with lots of grey recall the days when half the 3G bandwidth cost in the 6 figure range a month, with loss and latencies were about the same as the 3G link. Yes it is a constrained environment relative to other options today, but there is nothing inherent in the BW, loss, latency, cost that limits the potential for use as a packet network. While we can't assume that everything is reasonable in the constrained environment, we also shouldn't be throwing out capabilities that history has proven useful simply because they are hard or cost a little more. > > => It doesn't. But this is a classical argument > which essentially says :'if you can't build it > now, wait for a few years and you'll fit everything > in'... well, as an engineer I don't have a major > problem with that, but if I was someone who's > trying to sell a wide range of products for > different market segments, and some of those > need to be limited in many ways to be sellable > at all, then I would have a problem with this > logic. Product decisions beyond what is technically possible don't belong in the discussion about standards. My son's 3-year old calculator has more low-power CPU & memory than the SGI workstation I had 10 years ago, and it would fit in a package small enough for a 3G handset (and has a longer battery life than my phone). I have to believe that there are better options out there now (at least 5 years after that device design was done), so the fact that a product team doesn't want to use those for a specific market is not a problem for the IETF. > > Again, to be able to improve the quality of the > draft, we need to point out *exactly* where > the relevant problems are. Margaret did some > of this already and it is being discussed. I only had time for a quick pass this morning, and don't expect to get much more this month. Not that my personal time should drive a WG schedule, but if Margret raised several questions, and my quick pass found fundamental issues, I would argue that this doc is not even close to ready for last call. > > => The document does NOT avoid DAD. The document > is aimed at a generic cellular host, and wherever > applicable, makes an applicability statement on the > 3GPP-specific cases. The reason DAD is not needed > in 3GPP, is that the way an address is allocated > leaves no room for on-link duplication. And still, > the document does not say, you MUST NOT do DAD, > it simply says that in *this* instance of a cellular > network, DAD is not needed. So if you just want > to implement it anyway, then go ahead. 'A cellular host SHOULD NOT perform Duplicate Address Detection...' While that is not a MUST NOT, it is a very strong instruction to avoid it. If it said something like 'A cellular host MAY choose NOT perform Duplicate Address Detection when it has other means to ensure uniqueness...' I would be less concerned. > > > Keep in mind > > that doing so precludes the use of RFC3041 addresses, so the > > applications where anonymity is most valuable (as one moves > > around and > > doesn't movement traced) are precluded. > > => This is not a problem and address privacy is already > supported without the need for DAD. > The 3gpp-advice draft, the cellular host draft > and 3GPP TS 23.060 can provide the exact details. If there is something specific that makes the statement true, it should be written here so people don't have to chase around to find it. The only thing that might make it true is that the router interface on the subnet will ALWAYS have the 'unique bit' set in an EUI-64 derived address, and will never use another format. This also presumes that the handset doesn't provide layer-2 bridging services to other locally connected devices. If it does that then there is no guarantee that some device on the allocated subnet will not collide. > > A non-zero probability of > > collision requires a mechanism to resolve duplicates, and > DAD is the > > currently defined one. If another one exists that makes > > more sense over > > a lossy air-link, we should consider replacing DAD because it will > > probably be more reliable in the general case as well. > > => It doesn't make sense if a host gets a /64 > prefix that can not be used by anyone else on > the cellular interface. See previous comment about L2 bridging by the handset/embedded device in a laptop ... Tony -------------------------------------------------------------------- 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] --------------------------------------------------------------------
