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] --------------------------------------------------------------------
