Re: updates to IPv6 over PPP spec.

srihari varada <[email protected]>
Newsgroups gmane.ietf.pppext
Message-ID <[email protected]>
Dear All:

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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.