Hello Ralph,

CPE (RR) in your diagram participate in prefix delegation.
And CPE and Subscriber PCs can use the same prefix delegation
mechanism to assign unique prefixes to the subscriber PCs.
This can be useful in scenarios where unique prefix assignment
is required on a shared link.

-Syam

On 8/23/06, Ralph Droms <[EMAIL PROTECTED]> wrote:
Syam - I'm feeling really dense at this point.  I don't understand
"unique prefix for host" and assigning the unique prefix for each
host between the CPE and the subscriber PC.  In your scenario, what
devices participate in PD in the diagram I included?  Is there a
description of the scenario I can read?

- Ralph

On Aug 23, 2006, at 1:14 PM, Syam Madanapalli wrote:

> Hello Ralph,
>
> On 8/23/06, Ralph Droms <[EMAIL PROTECTED]> wrote:
>> Questions in line...
>>
>> - Ralph
>>
>> On Aug 23, 2006, at 3:54 AM, Syam Madanapalli wrote:
>>
>> > Hi,
>> >
>> > On 8/23/06, Ole Troan <[EMAIL PROTECTED]> wrote:
>> >> I don't understand the rationale for this work either.
>> >>
>> >> the first PD proposal (by Brian Haberman) was indeed based on
>> using
>> >> ICMP as transport. separate message types instead of
>> >> piggy-backing on RS/RA though. as we continued to develop that
>> >> mechanism we realised that we were pretty much reinventing the
>> DHCP
>> >> protocol machine. that realisation led to specifying it as an DHCP
>> >> option instead of as a new protocol.
>> >
>> > Currently DHCP mechanism works only between routers whereas this
>> > new mechanism works for end hosts. This draft just introduces a
>> flag
>> > in Prefix Information Flag (PIO) to indicate that the prefix is
>> > unique for
>> > the device. And another flag in RS to inform the routers that the
>> > host is
>> > looking for a unique prefix.
>>
>> Perhaps we need to back up and understand the application better.  In
>> DHCPv6 PD, we labeled the client node as "requesting router" because
>> PD seems only applicable in the case where the DHCPv6 client is
>> acting as a router between some links (to which the delegated
>> prefixes will be assigned) and the interface through which the
>> delegated prefix was assigned.  Is the ICMP PD proposal addressing
>> some different scenario?  If so, where can I learn about it?
>
> What I mean is that the prefix delegation mechanism can be used
> to assign unique prefixes for the hosts. Prefix Delegation and
> assigning
> unique prefixes may be different conceptually but the same mechanism
> can be used for both.
>
>>
>> > Currently we use RS/RA to discover the prefixes available on the
>> link
>> > (shared prefixes), I think it is natural to extend this for hosts
>> > to get unique
>> > prefixes.
>>
>> Where are these unique prefixes being used?  On the link between the
>> aggregation device and the CPE or between the CPE and the subscriber
>> CPEs in the diagram below?
>
> It's between CPE and Subscriber PC - unique prefixes for subscriber
> PCs.
>
> - Syam
>
>>
>>
>>                  ______________________                 \
>>                 /                      \                 \
>>                |    ISP core network    |                 \
>>                 \__________ ___________/                   |
>>                            |                               |
>>                    +-------+-------+                       |
>>                    |  Aggregation  |                       | ISP
>>                    |    device     |                       | network
>>                    |  (delegating  |                       |
>>                    |    router)    |                       |
>>                    +-------+-------+                       |
>>                            |                              /
>>                            |DSL to subscriber            /
>>                            |premises                    /
>>                            |
>>                     +------+------+                     \
>>                     |     CPE     |                      \
>>                     | (requesting |                       \
>>                     |   router)   |                        |
>>                     +----+---+----+                        |
>>                          |   |                             |
>> Subscriber
>>   ---+-------------+-----+- -+-----+-------------+---      | network
>>      |             |               |             |         |
>> +----+-----+ +-----+----+     +----+-----+ +-----+----+    |
>> |Subscriber| |Subscriber|     |Subscriber| |Subscriber|   /
>> |    PC    | |    PC    |     |    PC    | |    PC    |  /
>> +----------+ +----------+     +----------+ +----------+ /
>>
>>
>> > Also, the subnet model that NetLMM WG wants to choose is to have
>> > a unique prefix for each MN. These extensions for RS/RA allows
>> > NetLMM hosts to be able to get unique prefixes in a better compared
>> > to current RS/RA messages.
>> >
>> >>
>> >> a technical comment on your proposal; how do you plan to support
>> >> shared links with multiple requesting routers? RAs are typically
>> >> multicast.
>> >
>> > Typically RAs are sent in unicast in response to an RS. When the
>> > router
>> > receives an RS with the prefix delegation request flag, the router
>> > must
>> > send an unicast RA.
>> >
>> > -Syam
>> >
>> >>
>> >> /ot
>> >>
>> >
>> >
>> --------------------------------------------------------------------
>> > IETF IPv6 working group mailing list
>> > ipv6@ietf.org
>> > Administrative Requests: https://www1.ietf.org/mailman/listinfo/
>> ipv6
>> >
>> --------------------------------------------------------------------
>>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------


--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Reply via email to