> I have been very consistent in that I want you to describe the > characteristics of the link. The device on the end could be either a > host or router, but the current focus on limited capability hosts is > preventing progress. The micro-handset *IS NOT SPECIAL*, so just get > over it. What you need is a standard way of using a link that has > different characteristics than other link technologies > already defined.
=> Tony, Your consistent claims that the draft is only considering size, weight ...etc is not accurate as I've explained in my earlier email (about moving forward). By this claim you're ignoring every 3GPP-specific section in the draft, which describes how to behave on those interfaces. So to re-iterate, the draft _already_ includes the information required for IPv6 over foo, but it also adds the minimal requirements. Splitting it into 10 documents is not what I'm concerned about. I want to make sure that each one of those 10 includes the right information. Simply assuming that starting over with a new document will solve technical problems is clearly not going to work, and we can't afford it (time wise). Hesham > > > > > In any case, I can't see that we have cut out any future > development > > based on having routers there even if we disable DAD (on the > > cellular link ONLY). Anyway this is not the important issue right > > now since the problem we are facing is widespread host deployment. > > You are talking about product design issues, not standards > development > issues. The standards issue is that we need to describe the > characteristics of a specific air-link technology so it can > be used in a > consistent manner with other link technologies across all > IPv6 capable > hosts AND routers. The longer people persist on trying to > solve day-job > problems by inisiting on solving the limited case first, > the longer it > will take to make any progress. > > I am not against making progress on a document that can be > used for 3G > host deployments. I just can't see any real need to special > case this > and limit the long term potential of the link just because > some people > thought time-to-market was more important than doing it right. > > Tony > > > > > > /Karim > > > > > > > -----Original Message----- > > > From: Tony Hain [mailto:[EMAIL PROTECTED]] > > > Sent: den 7 mars 2002 20:10 > > > To: Hesham Soliman (ERA); [EMAIL PROTECTED] > > > Subject: RE: Cellular host draft - where we are and > suggestions for > > > moving forward. > > > > > > > > > Hesham, > > > > > > I appreciate where you are trying to go, but I think you are > > > still being > > > blinded to issues because the focus is to centric on *host*. > > > Yes people > > > are motivated to worry about that problem first, but > making design > > > assumptions based on the mobile device on the end of an > > > air-link being > > > limited to a host will cause problems. The current logic > > > appears to be > > > 'we don't want to do DAD, so define the link in terms of a > > > host so it is > > > unnecessary, then worry about a router later'. The > host perspective > > > should always be a subset of the demands of a link > technology, so > > > starting there will only assure that the link can never be > > > used outside > > > that scope. A group that is so focused on overhead of > bits on the > > > air-link should really be concerned about the impact of > > > forcing a router > > > to use IPv6 over IPv6 tunneling to get a reasonable > > service over it. > > > > > > As a specific comment to your note, rather than assume that > > > implementations will end up with an MTU of 1280, simply > > > state that the > > > interface MTU == 1280. In any case the infrastructure > > components will > > > have to respond appropriately to nodes that implement > > PMTU, so don't > > > assume that it won't happen just because it is not required > > > for devices > > > that are directly attached. > > > > > > Tony > > > > > > > > > > > > > -----Original Message----- > > > > From: [EMAIL PROTECTED] > > > > [mailto:[EMAIL PROTECTED]]On Behalf Of Hesham > > > > Soliman (ERA) > > > > Sent: Thursday, March 07, 2002 9:58 AM > > > > To: [EMAIL PROTECTED] > > > > Subject: Cellular host draft - where we are and > > > suggestions for moving > > > > forward. > > > > > > > > > > > > Hi all, > > > > > > > > I think we're having a pretty useful discussion > > > > about this draft which has highlighted a number > > > > of issues that need to be addressed. This > > > > is an attempt to summarise the issues that were > > > > discussed and see if we can find a way forward. > > > > > > > > Please note, this is not to suggest 1, 2 or 3 > > > > drafts ...etc, this is an attempt to resolve the > > > > technical issues first, editing them in documents > > > > is another issue that can be handled after we > > > > agree on what we're going to put in such documents. > > > > > > > > Before I list the issues and responses, I'd like > > > > to highlight an important point: This draft attempts > > > > to do 2 things: > > > > > > > > - Define the behaviour of a cellular host residing > > > > on a cellular link (in this case we only know of > > > > 3GPP networks because no one else has defined > > > > the use of IPv6 in their specific link) > > > > > > > > - List the host implementation requirements in > > > > a cellular network (not only 3GPP) based on > > > > the common characteristics of these networks > > > > (p2p channels, BW, resilience over the air > > > > interface ...etc) > > > > > > > > Perhaps the two points above can be separated > > > > in 2 documents, but I'm really interested in > > > > getting an agreement on the technical issues > > > > _first_. Editorial issues are secondary here. > > > > > > > > So the main issues that were brought up so far are > > > > (please let me know if I missed a major issue): > > > > > > > > Issue: What is a cellular host ? > > > > > > > > Suggestion: A cellular host is _any_ host that > > > > has a cellular interface. This would include > > > > low end devices like basic phones and high > > > > end devices like laptops. Low end devices will > > > > generally follow the behavioural aspects of > > > > the draft as well as the minimum implementation > > > > requirements, due to the lack of computing capacity. > > > > However, high end devices will implement whatever > > > > they want, but MUST follow the required behaviour > > > > _on_the_cellular_ interface. > > > > Please note that when it comes to implementation > > > > requirements, the draft never suggests that > > > > a standard MUST NOT be implemented, so everyone > > > > is free to implement more. The draft aims at > > > > the minimum, interoperable implementation. > > > > > > > > Issue: The use of the word 'terminal' is > > > > confusing. > > > > > > > > Suggestion: replace 'terminal' with Host. > > > > This was a mistake anyway. > > > > > > > > Issue: Should DAD be disallowed > > > > > > > > Answer: DAD for the general cellualar > > > > case is allowed in the draft. > > > > In the 3GPP-sepcific case, DAD is not needed because: > > > > > > > > - The link is p2p > > > > > > > > - The link-local address is given to the > > > > cellular host (it can't reject it). > > > > > > > > - A /64 is given to the cellular host _only_ > > > > > > > > - The GGSN will ensure the uniqueness of llA > > > > and will not use the host's /64 to configure > > > > any of its global addresses. The same goes > > > > for site-local if used. > > > > > > > > So DAD is not needed. This is analogous to > > > > a design decision to always assume an MTU > > > > of 1280, PMTU implementation becomes superfluous > > > > if the host will _never_ send a packet larger > > > > than 1280. > > > > I think we should close this issue unless someone > > > > points out a flaw above. > > > > > > > > Issue: Should IPsec be mandated? > > > > > > > > Suggestion: We should mandate AH and ESP for > > > > all hosts, following RFC2460. > > > > > > > > Issue: Should ND be mandated? > > > > > > > > Answer: ND is mandated in the draft. > > > > Certain options are not mandated on cellualar > > > > links (like LLA suboption) because it's not > > > > relevant. NUD is a MAY because there are > > > > other ways of detecting reachability in > > > > these links. If multiple default routers exist > > > > RSs and RAs will detect the failure of one > > > > of those routers. > > > > > > > > Issue: Stateless address autoconfig (2462) > > > > allowed? > > > > > > > > Answer: Yes it's allowed for the general > > > > cellualr case. However for the 3GPP case > > > > stateless address allocation works differently > > > > from RFC2462 (and does not break 3041), so > > > > come parts of RFC2462 are not relevant > > > > (the DAD part again!) > > > > > > > > Comments so far? Are these suggestions/answers > > > > accepatable? > > > > > > > > It took me 2.5 hours to write this email because > > > > of my wonderful mail server, so I probably > > > > won't be able to give quick responses. > > > > > > > > Hesham > > > > > > > > > > -------------------------------------------------------------------- > > > > 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] > > > -------------------------------------------------------------------- > > > -------------------------------------------------------------------- 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] --------------------------------------------------------------------
