Tony, > 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.
=> I think there is a bigger misunderstanding here that perhaps isn't obvious to one of us (you or me). What implications do you see (regarding DAD) which would cause us to distinguish between a host or a router? In the example I gave to Keith, if you have a router there are 2 separate links. The same rules about DAD on the cellular interface would still apply. What am I missing? > 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. => Sure, PMTU was used as an analogy. The difference of course is that DAD is link specific, so once you define the behaviour on a certain link, you know thatit will be interoperable for all devices with interfaces on that link. Hesham > > 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] --------------------------------------------------------------------
