In your previous mail you wrote:
(1) The Duplicate address detection shouldn’t be recommended to be
disabled, if the IPv6CP negotiates interface identifier with the peer.
=> as I have no concern about (1) I disagree with the rationale.
*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.
=> this makes sense if and only if you suggest that a 3GPP terminal
can change its PPP peer without shutting down PPP???
(b) RFC 2462, section 5.4 states that if there is a group of
addresses that are generated from a given interface identifier, the
Link-Local address MUST at least be tested for uniqueness. It is
likely that an interface would have multiple addresses (Link Local,
site-local and global scope addresses, for instance). This would
then necessitates the Link-Local address to be tested for
uniqueness. Thus, the text needs to be changed for consistency
reasons."
=> we agreed in the WG that DAD is really per address and not per
interface ID so MUST be done for every addresses (perhaps at the
exception of the link-local using the negociated IID).
4. RA (Route Advertisement) should be mentioned somewhere in the
Document for global unicast address configuration and other
configuration parameters. In IPCP, the IP address is part of the IPCP.
But in IPv6CP, only the interface ID is negotiated and link local is
auto-configured. For a new comer, it took us a while to figure out that
RA is used to configure the rest of stuff.
=> I disagree, this implies the PPP link is between an host and a router
when two other cases are possible.
5. Default ordering of IPv6CP and IPCP negotiation in a dual stack mode
should be explained -- RFC 1661 says that there could be one or more
NCPs in one PPP link. During inter-operability testing, we found some
vendors started NCP with IPv6CP and others with IPCP. It will evetually
work. But some extra messages will be dropped because of miss match. It
will be good to document the relationship between IPv6CP and IPCP in a
dual stack mode. Of course, the order should be configurable by the user
and one of them may be disabled in a single stack mode (either IPv4 only
or IPv6 only).
=> this is not in the scope of the WG: if some implementations don't support
parallel NCPs either they need to be fixed or the PPP specifications should
forbid this.
6. The Interface Identifier section should mention an exception (due to
the need for privary addresses) to the suggestion of consistent
reproduction of the interface identifier -- RFC 2472 states that the
interface identifier is suggested to be consistently reproducable across
initializations of the IPv6CP finite state machine (see section 4.1).
The text should be elaborated to include an exception as identified by
the Privacy Extensions for Stateless Address Autoconfiguration in IPv6
(RFC 3041).
=> I am not convinced this is really useful because the IID can be used
only for the link-local address which is not supposed to leak outside
the link...
Regards
[EMAIL PROTECTED]
PS: BTW I haven't seen a call for the agenda?
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
