Actually there is an operational simplicity case to be made for hosts doing
PD. In the scenario where the ISP wants to provide a 1:1 mapping between
customer & prefix, but the customer hasn't acquired a router yet. This can
be done with discrete RAs when customers are on independent interfaces, but
on shared media (HFC) there would need to be a hack to RAs to unicast them,
or host based PD.
Tony
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
> Christian Huitema
> Sent: Monday, May 10, 2004 10:19 AM
> To: Ralph Droms; JINMEI Tatuya / ????
> Cc: [EMAIL PROTECTED]
> Subject: RE: the protocol for the O flag
>
> Prefix delegation is a somewhat different animal than your average DHCP
> lookup. It only makes sense in routers, not hosts. In fact, it is unclear
> whether the DHCP server for prefix delegation should be the same as the
> DHCP server for DNS configuration. I think we should leave prefix
> delegation out of this discussion.
>
> > -----Original Message-----
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
> Ralph
> > Droms
> > Sent: Monday, May 10, 2004 9:40 AM
> > To: JINMEI Tatuya / [EMAIL PROTECTED]@C#:H
> > Cc: [EMAIL PROTECTED]
> > Subject: Re: the protocol for the O flag
> >
> > Yes, your original analysis is correct...
> >
> > Seems like the protocol associated with the 'O' bit should be RFC 3736;
> > there is no particular advantage to using the 4 message exchange of RFC
> > 3315
> > for "other configuration information". The only potential advantage
> would
> > be if there is ever a need for "other configuration information" that
> > needs
> > atateful assignment; we've never found a need for such assignment in
> > DHCPv4.
> >
> > Although exactly where prefix delegation falls is a little unclear...
> >
> > - Ralph
> >
> > At 12:42 AM 5/11/2004 +0900, JINMEI Tatuya /
> > =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote:
> > >(changing the subject)
> > >
> > > >>>>> On Sat, 08 May 2004 23:39:20 +0900,
> > > >>>>> JINMEI Tatuya <[EMAIL PROTECTED]> said:
> > >
> > > >> I think the O flag (if we keep it!) should simply specify DHCPv6,
> > with no
> > > >> implication about the way in which DHCPv6 is used.
> > >
> > > >> "Stateless DHCPv6" is simply a way to use some of the messages from
> > > the full
> > > >> specification in RFC 3315. RFC 3376 is a guideline to the
> > > implementation of
> > > >> DHCPv6 that uses just Information-request/Reply messages. A client
> > can
> > > >> choose to use the Request/Reply or the Information-request/Reply
> > message
> > > >> exchange to obtain other configuration information without address
> > > assignment.
> > >
> > > > Before going to further details, please let me clarify one thing
> about
> > > > RFC3736 (you should have meant RFC3736 by "RFC 3376" BTW).
> > >
> > > > In my understanding, RFC3736 defines a certain class of
> implementation
> > > > that is a subset of RFC3315, even though RFC3736 is basically a
> > > > "guideline". Specifically, RFC3736 defines the implementation class
> > > > in its Section 5.
> > >
> > > > So, there can be four types of servers and clients:
> > >
> > > > A. servers that conform to RFC3315. (These servers also conform to
> > > > RFC3736)
> > > > B. clients that conform to RFC3315 (These servers also conform to
> > > ^^^^^^^should be
> "clients"
> > > > RFC3736)
> > > > C. servers that only conform to RFC3736 (and do not implement the
> rest
> > > > of RFC3315)
> > > > D. clients that only conform to RFC3736 (and do not implement the
> rest
> > > > of RFC3315)
> > >
> > > > Is the above understanding correct?
> > >
> > >No responses...so, assuming the understanding is correct, I believe
> > >the best protocol for the O flag is the subset of RFC3315 as defined in
> > >RFC3736 (aka "stateless DHCPv6"). The rationale is as follows:
> > >
> > >As long as we need to care about type D clients (which do not support
> > >full RFC3315), servers must be configured to enable RFC3736, whether
> > >they can also support full RFC3315 or not.
> > >
> > >But then, I don't see the reason for leaving flexibility by specifying
> > >a larger set (i.e., RFC3315) as the protocol for the O flag.
> > >
> > >If we specify RFC3736 as the protocol,
> > >
> > >- type A servers will be configured to act as RFC3736 servers (they
> > > may also act as full RFC3315 servers, but that doesn't matter here).
> > >- type B clients will perform RFC3736 to get the "other" configuration
> > > information, as a subset of their full ability.
> > >- type C servers will simply act as RFC3736 servers
> > >- type D clients will simply act as RFC3736 clients
> > >
> > >On the other hand, if we just specify RFC3315 as the protocol, we'll
> > >be bothered about combination issues. In the following discussion,
> > >I'll call other configuration by request/reply exchanges "stateful
> > >other configuration".
> > >
> > >- type A servers will at least need to be configured to enable
> > > RFC3736, as explained above. They may or may not enable the rest of
> > > RFC3315.
> > >- type B clients may perform RFC3736 only, stateful other
> > > configuration only, or both.
> > > + if the client only tries RFC3736, it will be happy, since type A
> > > servers should act as RFC3736 servers (type C servers can of
> > > course serve for the client).
> > > + if the client only tries stateful other configuration, the
> > > configuration will fail when type A servers do not enable stateful
> > > other configuration or there are only type C servers.
> > > + if the client tries both RFC3736 and stateful other configuration,
> > > what happens depends on the ordering. If it first tries RFC3736
> > > or performs both concurrently, it will be happy. If it first
> > > tries stateful other configuration, the client can see a long
> > > delay before the configuration completes when type A servers do
> > > not enable stateful other configuration or there are only type C
> > > servers.
> > >- type C servers will simply act as RFC3736 servers. If there are
> > > type B clients that do not try RFC3736, the servers cannot serve for
> > > the clients.
> > >- type D clients will simply act as RFC3736 clients. The clients will
> > > be happy, since type A servers should act as RFC3736 servers (type C
> > > servers can of course serve for the client).
> > >
> > >As shown above, a type B client can easily get stuck unless it is very
> > >carefully configured; to be able to configure itself in all the
> > >possible scenarios, the client will need to perform RFC3736 only,
> > >tries RFC3736 first (which should succeed), or tries both RFC3736 and
> > >stateful other configuration concurrently (at least the former should
> > >succeed). Then, why can't we simply specify RFC3736 as the protocol?
> > >
> > >Meanwhile, leaving the flexibility may make sense if it has a clear
> > >advantage comparing to specify RFC3736 clearly. Regarding other
> > >configuration information, however, I don't see such an advantage that
> > >outweighs the complexity shown above.
> > >
> > >Comments?
> > >
> > > JINMEI, Tatuya
> > > Communication Platform Lab.
> > > Corporate R&D Center, Toshiba
> > Corp.
> > > [EMAIL PROTECTED]
> > >
> > >--------------------------------------------------------------------
> > >IETF IPv6 working group mailing list
> > >[EMAIL PROTECTED]
> > >Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> > >--------------------------------------------------------------------
> >
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [EMAIL PROTECTED]
> > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [EMAIL PROTECTED]
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
