The rationale also fails to account for 3GPP2 networks (cdma2000). Here, PPP (IPV6CP) is used to obtain an IPv6 address for the mobile (or the MIPv6 CoA for the mobile). UMTS uses a PDP context instead.
Since 3GPP2 has mandated a restriction that the /64 prefix advertised to a mobile by a PDSN (similar to 'GGSN' if you are a UMTS-only person) be unique/exclusive to that PPP link, then there is no need for the suggested update #1 below. In fact, quite the contrary. - Pete -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Karim El-Malki (HF/EAB) Sent: Wednesday, February 11, 2004 1:42 PM To: 'srihari varada'; [EMAIL PROTECTED] Cc: Brian Haberman; Bob Hinden; Alex Conta; [EMAIL PROTECTED] Subject: RE: updates to IPv6 over PPP spec. > (1) The Duplicate address detection shouldn't be recommended to be > disabled, if the IPv6CP negotiates interface identifier with > the peer. > * > * > > *Rationale:* > > (a) In the mobile (3GPP) networks the host isn't stationary. As > such, the interface identifier uniqueness may not be ensured at > different space points in the provider network (for > instance, in the > case of randomly generated Interface Identifier). This would then > warrant the mobile host to trigger duplicate address detection as > and when it changes it's position. (a) doesn't seem correct to me. In terms of 3GPP nets the host is stationary with respect to its default router. Also as recommended in RFC 3314 an entire /64 is assigned to a mobile's connection so DAD is not useful. Looks to me like the 3GPP case would actually be in favour of disabling DAD. /Karim This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
