Hi Rajan,
Rajan Srivastava wrote:
Hi Greg,
Thanks for the kind & prompt response. What you mentioned is correct; but this kind of provision in IPv6 framework has resulted in more complex implementations.
Eg., if PPP server would have allocated
one prefix to PPP client (in IPv6CP) then the client would become a globally routable
host; and the PPP client might use this prefix as per his requirements;
and multiple prefix allotment could also take place in the same way as
defined in IPv6 RFCs!
Yes this is one way it could have been done.
In PPP (RFC 1661) each end of the PPP session needs to understand a particular Configuration Option, or it will be Configure-Rejected.
At this stage, there is no Prefix Configuration Option for IPv6CP, and implementing on one device may lead to a situation where the option is not recognized by the other.
This leads to a Configure-Reject and another IPv6CP round trip.
If we use IPv6 Neighbour Discovery/Router Discovery then the (potentially) multiple prefixes are provided in the (extra) message exchange used for Neighbour Discovery.
This extra potential round trip goes away if the PPP endpoints both understand the Prefix Configuration Option.
But since things are not defined in this way, PPP client and server both have to have DHCPv6 client/server implemented on them; making both the systems (PPP client & server) more complex!
DHCPv6 is not required (except as specified in the Node requirements document).
Neighbour Discovery (RFC2461) and Stateless Address Autoconfiguration (RFC2462) are sufficient.
These are MUST implement in Node requirements anyway.
I'm not saying it's not worth doing (Specifying a Prefix Configuration Option), but that it has some tradeoffs when addressing compatability.
Greg
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
