Subject: IPv6CP - rfc 2472 --- why only IID, why not prefix too

From: "Rajan Srivastava" <[email-masked]>
Date: Wed, 24 Nov 2004 18:08:35 +0530

Hi,

In rfc 2472, it is provisioned that PPP server will negotiate
interface identifier with PPP client, server will not pass on network 
prefix;
and prefix delegation is left for DHCPv6 etc.

What is rationale behind this strategy?

thanks & regards
Rajan

_________________________________________________________________
NRIs! Easy to send, easy to receive! 
http://creative.mediaturf.net/creatives/citibankrca/rca_msntagofline.htm Ask 
us how!

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Greg Daley <[email-masked]>
Date: Thu, 25 Nov 2004 13:09:05 +1100

Hi Rajan,

> What is rationale behind this strategy?

IP(v4)CP believes that the peer PPP device can only have one address.

In IPv6, there's a lot more flexibility regarding prefix utilization
on a host or network.

IPv6 Link-Local addresses have a fixed 64 bit upper portion, and so
the 64 bit token used for IP6CP may be usable to generate a valid
Link-Local address.

Such an address can then be used in DHCP, or Neighbour Discovery.

Since Router Discovery (part of Neighbour Discovery) can provide
multiple prefixes to a host, any one or more of these prefixes
may be used to autoconfigure an address.

As you mentioned, prefix delegation caters to another set of devices:
those requiring networks/prefixes of addresses.

Each fills its own requirement, and it doesn't necessarily make sense
to define another way to do this in IP6CP, since the assumptions
are different to IPv4.

Yours Sincerely,

Greg Daley

---

From: "Rajan Srivastava" <[email-masked]>
Date: Thu, 25 Nov 2004 12:14:53 +0530

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!

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!

Thanks & regards
Rajan

>From: Greg Daley <[email-masked]>
>Reply-To: [email-masked]
>To: Rajan Srivastava <[email-masked]>
>CC: [email-masked]
>Subject: Re: IPv6CP - rfc 2472 --- why only IID, why not prefix too
>Date: Thu, 25 Nov 2004 13:09:05 +1100
>
>Hi Rajan,
>
>Rajan Srivastava wrote:
>>Hi,
>>

_________________________________________________________________
Protect your PC! Call in the experts! http://www.msn.co.in/security/ Click 
here now!

---

From: Greg Daley <[email-masked]>
Date: Fri, 26 Nov 2004 10:43:26 +1100

Hi Rajan,

Rajan Srivastava wrote:
> one prefix to PPP client (in IPv6CP) then the client would become a 
> globally routable

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.

> on them; making both the systems (PPP client & server)

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