As broadcasted on the IPv6 and PPPext mailing lists some time back, we are soliciting input to update the RFC 2472. Provided below is the input received so far from the IPv6 community on the IPv6 over PPP spec. Please review and make any additions to the list at your earliest convenience. If no further input is received in the next few days or so, consensus is assumed and edits to the spec. would be initiated.
(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.
(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."
2. Update the reference section with corrected URL to guidelines for EUI-64 assignment. Alternatively, remove the URL altogether, but keep the reference identifying IEEE.org as the source.
3. Review and clarify the IPv6 over PPP specification to match the current IPv6 addressing architecture. (as stated in RFC 3314)
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.
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).
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).
Regards,
Srihari Varada
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
