Subject: [dhcwg] DHCPv6 Client address prefix

From: "Mike Taylor" <[email-masked]>
Date: Tue, 19 Aug 2008 09:16:37 -0700

Hello All,

Can someone authoritatively clear up the issue of where a DHCPv6 client gets
the address prefixes (lengths) for addresses assigned by a DHCPv6 server.

My understanding is that an IPv6 client gets the prefixes from router
advertisements
and installs routes to those prefixes.  The DHCPv6 server only assigns
addresses
and presumably must be configured so that those addresses have prefixes that
match those that are advertised by routers on the client's link.  So this
implies
that the receipt of addresses from a DHCPv6 server does not cause the client
to install routes to IPv6 subnets.  Only the router advertisements would do
that.
Of course, if there were not router advertisements this would appear to be
problematic.  

However recently someone told me that he learned from an IPv6 "expert" that
the prefix length of all addresses assigned by a DHCPv6 server is /64.  That
doesn't seem correct to me, unless the implication was that /64 would be the
prefix length to use if there were no routers advertising prefixes on the
link.

Perhaps this should be obvious but in an hour or more of googling I have not
been
able to find anything like a definitive answer to this rather fundamental
issue.
It does not seem to be addressed in RFC3315 but I could be missing it.  

Thanks,

Mike

_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: "David W. Hankins" <[email-masked]>
Date: Wed, 20 Aug 2008 09:14:51 -0700

> the address prefixes (lengths) for addresses assigned by a DHCPv6 server.

Probably not.

> prefix length to use if there were no routers advertising prefixes on the

It isn't a server issue, but rather a client one.

Some clients have discovered that if the router is offline, then even
if DHCPv6 succeeds in allocating an address it won't be able to reach
other devices on the local wire (e.g., the recursive dns resolvers
learned through DHCPv6, or any other local-to-the-wire service learned
through DNS; these are likely to use global addresses even though link
locals could do).

Consequently, some client implementations presume a /64 for
compatibility.  So things work while the router is down, or in some
stranger networks where there isn't one on purpose.

> It does not seem to be addressed in RFC3315 but I could be missing it.  

RFC 3315 is not explicit on this subject.  The claim is that an
address provided in an IAADDR is implicitly a /128, and an IPv6
network with no router up and running is intentionally broken.

-- 
Ash bugud-gul durbatuluk agh burzum-ishi krimpatul.
Why settle for the lesser evil?	 https://secure.isc.org/store/t-shirt/
-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		     you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins
_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Frank Xia <[email-masked]>
Date: Wed, 20 Aug 2008 11:38:22 -0500

DHCPv6 Client address prefixHi Mike

There is no automated synchronization mechanism between
prefixes for clients address configuration and prefixes
for routing information advertisment by a router.

The common practice is using aggregated prefix for
rout information advertisement.

BR
Frank

  ----- Original Message ----- 
  From: Mike Taylor 
  To: [email-masked] 
  Sent: Tuesday, August 19, 2008 11:16 AM
  Subject: [dhcwg] DHCPv6 Client address prefix

  Hello All,

  My understanding is that an IPv6 client gets the prefixes from router advertisements

  and installs routes to those prefixes.  The DHCPv6 server only assigns addresses

  match those that are advertised by routers on the client's link.  So this implies

  to install routes to IPv6 subnets.  Only the router advertisements would do that.

  problematic.  

  prefix length to use if there were no routers advertising prefixes on the link.

  Perhaps this should be obvious but in an hour or more of googling I have not been

  able to find anything like a definitive answer to this rather fundamental issue.

  Thanks,

  Mike

------------------------------------------------------------------------------

---

From: Francis Dupont <[email-masked]>
Date: Thu, 21 Aug 2008 01:28:46 +0200

In your previous mail you wrote:

=> nowhere, it is *not* a part of DHCPv6.

=> you're right.

=> you're still right.

=> /64 is a good hint but there are many places where another value is used
(for instance I am typing this message from a /56 link prefix).

=> DHCPv6 was not designed to work without RAs. The prefix length is
a missing parameter, a default router address another one.

Regards

[email-masked]
_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 20 Aug 2008 20:40:31 -0400

Please check the archives of this mailer up to one year back and see all
my comments on such questions.  I have said repeatedly to this mailer
that DHCPv6 has no option related to carrying prefix length.  It is
deliberate design for IPv6 where the router that sends the RA sends the
prefix length in Prefix Information Option.  

/64 is only mandated to be a default prefix length for SLAAC clients.  A
DHCPv6 client cannot assume a /64.  Also check the IETF 6man mailer for
such discussions by myself and Wes Beebee.  

Hemant 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Francis Dupont
Sent: Wednesday, August 20, 2008 7:29 PM
To: Mike Taylor
Cc: [email-masked]
Subject: Re: [dhcwg] DHCPv6 Client address prefix

   Can someone authoritatively clear up the issue of where a DHCPv6
client gets
   the address prefixes (lengths) for addresses assigned by a DHCPv6
server.

   My understanding is that an IPv6 client gets the prefixes from router
   advertisements
   and installs routes to those prefixes.  The DHCPv6 server only
assigns
   addresses
   and presumably must be configured so that those addresses have
prefixes that
   match those that are advertised by routers on the client's link.  So
this
   implies
   that the receipt of addresses from a DHCPv6 server does not cause the
client
   to install routes to IPv6 subnets.  Only the router advertisements
would do
   that.

=> you're right.

   Of course, if there were not router advertisements this would appear
to be
   problematic.  
   
=> you're still right.

   However recently someone told me that he learned from an IPv6
"expert" that
   the prefix length of all addresses assigned by a DHCPv6 server is
/64.  That
   doesn't seem correct to me, unless the implication was that /64 would
be the
   prefix length to use if there were no routers advertising prefixes on
the
   link.
   
=> /64 is a good hint but there are many places where another value is
used (for instance I am typing this message from a /56 link prefix).

   Perhaps this should be obvious but in an hour or more of googling I
have not
   been
   able to find anything like a definitive answer to this rather
fundamental
   issue.
   It does not seem to be addressed in RFC3315 but I could be missing
it.  
   
=> DHCPv6 was not designed to work without RAs. The prefix length is a
missing parameter, a default router address another one.

Regards

---

From: "David W. Hankins" <[email-masked]>
Date: Thu, 21 Aug 2008 08:11:03 -0700

> DHCPv6 client cannot assume a /64.  Also check the IETF 6man mailer for

It also cannot assume a /128, as this results in non-interoperability.

This is a problem we could easily clear up by including a simple
prefix length along with the IAADDR; in its absence, you can now
safely assume a /128 was intended by the network operator.  In its
presence, you still interoperate.

I'm probably going to make such an option in ISC's VSIO space, but
I cannot assume the same thing.  Someone who doesn't know about ISC's
peculiar VSIO's can't be expected to set our prefix length, so we
will have to retain a compatible default.

The criticism however is that merely the prefix length is an
incomplete set of information; the suggestion is to include the full
PIO contents in DHCPv6 replies.

I don't fully understand the suggestion, as it has something to do
with "not on link" prefixes, which are supposed to mean that although
you're all on the same broadcast domain you're still expected to send
your packets through a default router to reach each other.  This seems
equivalent in results to setting /128 to me, but I guess the bit
wouldn't be in the PIO if there weren't some important distinction.

---

From: Ralph Droms <[email-masked]>
Date: Thu, 21 Aug 2008 11:32:20 -0400

I look at this prefix issue somewhat differently.

As I read the IPv6 specs, there is no prefix length associated with an  
address, per se.  When used as a destination address for datagram  
forwarding, the address is used as a string of 128 bits, and compared  
against the entries in the host forwarding table.  Each of those  
entries has an associated prefix length, which is used to decide how  
many bits of the destination address and forwarding table entry should  
be compared.  So, in my opinion, there is a prefix length for each  
forwarding table entry, but no prefix length associated with an address.

Now, as a matter of convenience or perhaps as a carryover from IPv4  
implementations, it seems many stacks allow the specification of a  
prefix length with an address assigned to a device interface.  This  
same thinking is sometimes used to call for the inclusion of a prefix  
length with addresses assigned by DHCPv6.  In these cases, the device  
stack assumes that the prefix derived from the assigned address and  
prefix length is on-link and an entry for that derived prefix is added  
to the device forwarding table.  In theory, I think this action is  
wrong.  Based on my understanding that there is no prefix associated  
with an address, there is no need to specify a prefix when assigning  
an address to an interface (either manually or through DHCPv6).

The IETF decided that prefix information should be provided to devices  
through RAs.  I understand this decision, as the assignment of  
addresses to an interface in a device is entirely separate from the  
notion that a prefix is associated with a link.

The recent change to the assumption that addresses are on-link now  
causes problems in the case where no RAs are provided to a device.  If  
the IETF chooses to address this problem, the correct solution would  
be to provide complete prefix information (either by carrying PIOs in  
DHCPv6 or carrying the necessary information in some other new  
option).  Associating a prefix length with assigned addresses might  
provide some help but would not be a correct solution.

- Ralph

---

From: "Mike Taylor" <[email-masked]>
Date: Thu, 21 Aug 2008 09:17:33 -0700

Yes, we have one of those stacks where, as a carry over from the IPv4-only
days, the function to assign an address to an interface includes a parameter
for the prefix length, and if it is not 128 then the stack will create a
directly connected route to that prefix.  We considered at one point that
maybe the prefix should not even be meaningful for IPv6 addresses and 
perhaps in some future release we'll make it official.

I think what we're seeing is that it is just plain hard for a lot of our
customers coming at IPv6 with only an IPv4 background to understand how it's
supposed to work, i.e., RAs provide prefixes, and DHCPv6 provides addresses.
To some I think it gives them a somewhat uneasy feeling that these addresses
and prefixes, which are fairly intimately related to each other, should
come from apparently completely different sources.  It seems like exactly
the kind of thing that invites inadvertent misconfiguration.  

The other thing that adds to the confusion is the fact that if an RA had
DNS name server addresses in it then probably 99% of PCs in people's homes
could obtain all the information they need from RAs and there would be
little need for putting a DHCPv6 server into the average SOHO router.

And perhaps some are confused as to why DHCPv6 should even provide 
IPv6 addresses rather than it being used only for name server addresses 
and other info like TCP MTUs etc.  But of course there are scenarios 
where network admins desire having finer control over the addresses 
provided to hosts than can be provided by auto-configuration via RAs 
alone.  

Anyway, for now I get the feeling that the official position, if there
really is any such thing, is that RAs are the sole source of prefixes,
and that the configuration of an address on an interface, in particular
when the address was received via DHCPv6, should not cause the creation
of a directly connected route to any prefix.  Such routes should really
only be created by RAs, or by intentional manual configuration by a
network admin, assuming that the IETF won't ever be able to claim that
this such manual configuration is prohibited (although it does seem like
a bad idea).  So having an API function that can configure an address 
and take a prefix length is still an option in that it provides an admin
with a somewhat simpler way to specify the address and prefix at the
same time.  

Regards,

Mike

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Ralph Droms
> Sent: Thursday, August 21, 2008 8:32 AM
> To: DHC WG

---

From: Bud Millwood <[email-masked]>
Date: Thu, 21 Aug 2008 22:33:55 +0200

> forwarding table entry, but no prefix length associated with an address.

There are a lot of options in DHCPv4 that aren't directly associated with a
specific IP address. Could it not be argued that DHCPv4 was not just about
assigning an address, but also very much about configuring a complete network
stack? That regardless of how DHCPv4 was percieved, in effect it was a
network stack configuration server?

If DHCPv6 were viewed the same way, then it would make sense to transmit a
prefix length, but *not* with an IAADDR - with a new IA network-config type
or something. In that case, clients could opt to request such information
during first stage initialization, but maybe not when simply extending
address leases.

- Bud

> > On Wed, Aug 20, 2008 at 08:40:31PM -0400, Hemant Singh (shemant)
> >
> > wrote:

-- 
Bud Millwood
Weird Solutions, Inc.
http://www.weird-solutions.com
tel: +46 8 758 3700
fax: +46 8 758 3687
_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Ralph Droms <[email-masked]>
Date: Thu, 21 Aug 2008 17:54:31 -0400

Bud - I agree with your conclusion about whether prefix information  
could reasonably be carried in DHCPv6.

The IETF has decided that ND is used to provide the information about  
what prefixes are on a link, under the assumption that RAs are always  
available and the design decision that two ways to provide the prefix  
information (RAs and DHCP) is redundant and is an opportunity for  
misconfiguration.

There is a scenario - no RAs and no on-link assumption - in which a  
host needs another mechanism to obtain information about prefixes.   
It's up to the IETF to decide whether DHCPv6 should be extended to  
solve this problem.

- Ralph

---

From: "Mike Taylor" <[email-masked]>
Date: Thu, 21 Aug 2008 15:01:31 -0700

> Sent: Thursday, August 21, 2008 2:55 PM
> To: Bud Millwood
> Cc: [email-masked]; Ralph Droms

As I understand it, the hard line on this is that a host shouldn't
even use DHCPv6 unless it gets router advertisements with the M
bit set.  I'm not saying I support this viewpoint (or that I don't,
I'm not a network admin) only that this is what I was told in another
email.  

/Mike

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 21 Aug 2008 18:59:07 -0400

Dream on, DHC folks who have said adding a prefix len option to DHCPv6
makes sense. I will personally not let that happen. 

As I have said earlier, please go and read my emails to this mailer as
to why I say such ideas don't make sense.  Since we have discussed such
issues copiously in the past year, I am not going to waste my time
repeating myself.  All I will do is jump is soon as a set of emails fly
by saying adding a prefix length to DHCPv6 makes sense.  It SO DOES NOT.

Also, cc such emails to 6man because by design it's ND in IPv6 that
deals with prefix length.  

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Mike Taylor
Sent: Thursday, August 21, 2008 6:02 PM
To: Ralph Droms (rdroms); 'Bud Millwood'
Cc: [email-masked]
Subject: Re: [dhcwg] DHCPv6 Client address prefix

> Of Ralph Droms

As I understand it, the hard line on this is that a host shouldn't even
use DHCPv6 unless it gets router advertisements with the M bit set.  I'm
not saying I support this viewpoint (or that I don't, I'm not a network
admin) only that this is what I was told in another email.  

/Mike

> >> As I read the IPv6 specs, there is no prefix length associated with

> >> an address, per se.  When used as a destination address for 
> >> datagram forwarding, the address is used as a string of 128 bits, 
> >> and compared against the entries in the host forwarding table.  
> >> Each of those entries has an associated prefix length, which is 
> >> used to decide how many bits of the destination address and 
> >> forwarding table entry should be compared.  So, in my opinion, 
> >> there is a prefix length for each forwarding table entry, but no 
> >> prefix length associated with an address.
> >
> > There are a lot of options in DHCPv4 that aren't directly associated

> > with a specific IP address. Could it not be argued that DHCPv4 was 
> > not just about assigning an address, but also very much about 
> > configuring a complete network stack? That regardless of how DHCPv4 
> > was percieved, in effect it was a network stack configuration 
> > server?
> >
> > If DHCPv6 were viewed the same way, then it would make sense to 
> > transmit a prefix length, but *not* with an IAADDR - with a new IA 
> > network- config type or something. In that case, clients could opt 
> > to request such information during first stage initialization, but 
> > maybe not when simply extending address leases.
> >
> > - Bud
> >

> >> same thinking is sometimes used to call for the inclusion of a 
> >> prefix length with addresses assigned by DHCPv6.  In these cases, 
> >> the device stack assumes that the prefix derived from the assigned 
> >> address and prefix length is on-link and an entry for that derived 
> >> prefix is added to the device forwarding table.  In theory, I think

> >> this action is wrong.  Based on my understanding that there is no 
> >> prefix associated with an address, there is no need to specify a 
> >> prefix when assigning an address to an interface (either manually 
> >> or through DHCPv6).
> >>
> >> The IETF decided that prefix information should be provided to 
> >> devices through RAs.  I understand this decision, as the assignment

> >> of addresses to an interface in a device is entirely separate from 
> >> the notion that a prefix is associated with a link.
> >>
> >> the IETF chooses to address this problem, the correct solution 
> >> would be to provide complete prefix information (either by carrying

> >> PIOs in

> >>> I cannot assume the same thing.  Someone who doesn't know about 
> >>> ISC's peculiar VSIO's can't be expected to set our prefix length, 
> >>> so we will have to retain a compatible default.
> >>>
> >>>
> >>> incomplete set of information; the suggestion is to include the 
> >>> full PIO contents in DHCPv6 replies.
> >>>

> >>> with "not on link" prefixes, which are supposed to mean that 
> >>> although you're all on the same broadcast domain you're still 
> >>> expected to send your packets through a default router to reach 
> >>> each other.  This seems equivalent in results to setting /128 to 
> >>> me, but I guess the bit wouldn't be in the PIO if there weren't 
> >>> some important distinction.
> >>>
> >>> --

---

From: Ralph Droms <[email-masked]>
Date: Thu, 21 Aug 2008 19:20:05 -0400

On Aug 21, 2008, at Aug 21, 2008,6:01 PM, Mike Taylor wrote:
>> [...]

RFC 4862 isn't crystal clear, but implies that a host MAY use DHCPv6  
even if it receives no RAs:

5.5.2.  Absence of Router Advertisements

    Even if a link has no routers, the DHCPv6 service to obtain  
addresses
    may still be available, and hosts may want to use the service.  From
    the perspective of autoconfiguration, a link has no routers if no
    Router Advertisements are received after having sent a small number
    of Router Solicitations as described in [RFC4861].

- Ralph

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 21 Aug 2008 19:51:03 -0400

Thanks, Ralph.  Yes, even such text has been discussed in 6man and/or
DHC mailer about one year back.  

However, in a router-less network, most bets are off for IPv6
configuration.  Such a network does expect hosts to be manually
configured for routes and prefix length, especially since RFC4943
mandated that on-link assumption is harmful in a router less network -
text from RFC4943 has been folded into RFF4861. 

No concrete justification exists to add prefix length to DHCPv6 - prefix
length is a primitive of ND and keep it that way.  Also see emails from
Bernie Volz last year when we discussed this issue in 6man and DHC
mailers.  Soon as we have two entities in ND RA and DHCPv6 server doling
out prefix length, who wins if a host finds mismatched information -
Bernie pointed out such a thing about one year back.  There are other
reasons too.  Please read archives of 6man and DHC mailers from about
one year back. 

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Ralph Droms (rdroms)
Sent: Thursday, August 21, 2008 7:20 PM
To: Mike Taylor
Cc: [email-masked]; 'Bud Millwood'; Ralph Droms (rdroms)
Subject: Re: [dhcwg] DHCPv6 Client address prefix

On Aug 21, 2008, at Aug 21, 2008,6:01 PM, Mike Taylor wrote:
> even use DHCPv6 unless it gets router advertisements with the M bit 
> set.  I'm not saying I support this viewpoint (or that I don't, I'm 
> not a network admin) only that this is what I was told in another 
> email.
>
>
> /Mike

- Ralph

---

From: "Mike Taylor" <[email-masked]>
Date: Thu, 21 Aug 2008 17:35:43 -0700

Hi Ralph,

Well that's interesting because it does beg the question what
would one do with such DHCPv6 addresses? There wouldn't
be a route to any on-link prefix corresponding to the
address so if the on-link assumption is not in force the
address would seem to be pretty useless.  Am I missing
something?  Well I guess if DHCPv6 can provide the address
of a default router then the box could just send packet to
it and the redirect would get it to the right destination.
I'm not actually to well versed in DHCPv6.  Does it have a
router option?  If not then it seems like RFC4862 ought to
be updated because otherwise this kind of verbiage will continue 
to beg the question why doesn't DHCPv6 provide prefixes?  Not
that I think that it should.  I'm just saying....

Regards,

Mike

> From: Ralph Droms [mailto:[email-masked]]
> Sent: Thursday, August 21, 2008 4:20 PM
> To: Mike Taylor
> Cc: Ralph Droms; 'Bud Millwood'; [email-masked]

---

From: Bud Millwood <[email-masked]>
Date: Thu, 21 Aug 2008 18:17:44 +0200

On Thursday 21 August 2008, Ralph Droms wrote:
> prefix length with an address assigned to a device interface.

- Bud

> This

---

From: Ted Lemon <[email-masked]>
Date: Thu, 21 Aug 2008 20:11:11 -0700

On Aug 21, 2008, at 5:35 PM, Mike Taylor wrote:
> would one do with such DHCPv6 addresses?

For my own part I don't really see the point of using anything but a  
link-local address on a routerless subnet.   So whatever the spec  
says, I think this is a bit of a moot point.

Do y'all see some reason why a link-local address wouldn't do the job  
in this situation?

---

From: Ralph Droms <[email-masked]>
Date: Fri, 22 Aug 2008 10:55:34 -0400

Ted - I agree that, in principle, link-local addresses should work in  
the case where there is no router on the link.

One technical issue is the need to specify an interface with a link- 
local address.  I haven't looked at the details - are applications  
typically being written to accommodate tying an interface to a link- 
local address?  Do IPv6 stack APIs typically allow for specification  
of an interface.

Another hypothetical issue is the desire to configure hosts on a link  
that does have routers and connectivity to other links without using  
RAs (sort of the converse of wanting to configure hosts without  
DHCP).  One scenario I've heard floated is host-specific configuration  
on a shared link (which could also be achieved through unicast RAs).   
Another set of similar scenarios is being addressed through the "rogue  
RA" I-D and discussion - where the network admin wants to avoid loss  
of host connectivity through misconfigured or malicious RAs.

- Ralph

On Aug 21, 2008, at Aug 21, 2008,11:11 PM, Ted Lemon wrote:

> Do y'all see some reason why a link-local address wouldn't do the  
> job in this situation?
>

---

From: Ted Lemon <[email-masked]>
Date: Fri, 22 Aug 2008 10:03:07 -0700

> local address?  Do IPv6 stack APIs typically allow for specification

Yes.   It's in the Advanced API RFC.   AFAIK, at least Linux and BSD  
implement the API - not sure about Windows.   Whether people will use  
it is another question.   However, there's a clear solution to this  
problem.   When transmitting to a link-local address on a machine with  
more than one interface, the routing layer needs to do ND on all  
interfaces.   I don't really see how it could do otherwise.   If it  
gets a response, that will install a host route to the desired link- 
local address, which in turn should affect source address selection  
and should result in packets going out the right interface.   So if  
this is a problem, it's a problem that can be solved in the kernel,  
without changes to applications.

> of host connectivity through misconfigured or malicious RAs.

Since hosts are effectively required to accept RAs, DHCP can't really  
help with this problem.   Even if you don't publish RAs on the wire,  
you're still potentially susceptible to DoS or MitM from rogue RAs,  
because the client has no way of knowing that RAs are not being used  
on the wire.   So I don't think this is a useful solution to the rogue  
RA problem.

As for custom-configuring hosts, we already have a way to do that - we  
send out RAs that disallow autonomous configuration and have the  
managed bit set.   Then the hosts have to use DHCPv6, and the DHCPv6  
server controls their configuration.

So none of these concerns seem to me to justify putting routing  
information in the RA.

I don't personally buy the argument that routing information shouldn't  
appear in two places, because we've actually had a bit of experience  
with changing views on how to do routing in IPv4.   But I don't see  
any tearing hurry to add these options, and I'm a bit concerned that  
adding them at this juncture will introduce interoperability problems  
we haven't anticipated.

When we went down this path in IPv4-land, what actually happened was  
that RIP was effectively deprecated, and so there was no real conflict  
between RIP and DHCP - by default RIP is simply turned off in most IP  
stacks.

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 22 Aug 2008 10:48:14 -0700

What about the scenario of the DHCPv6 server being
co-located with an on-link router? Can there be
some indication from the DHCPv6 server to indicate
this relationship?

Fred
[email-masked]  
_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Ted Lemon <[email-masked]>
Date: Fri, 22 Aug 2008 11:12:15 -0700

> some indication from the DHCPv6 server to indicate

Why would that be useful?