Subject: Solutions for distributing RFC 3484 address selection policies

From: Stig Venaas <[email-masked]>
Date: Wed, 10 Aug 2005 09:42:03 +0200

So far two principal solutions have been suggested, RAs and DHCP. If
people want to work on solutions we could possibly look into both of
these.

Some issues have already been mentioned on this list. Another issue
which was brought up in dhc wg, is that the policy is a host global
config, not per interface. This might be an issue when you have
multiple interfaces. This needs to be considered for both RAs and
DHCP.

I have two problems with RAs. One is that all hosts on the link will
get the same policy. The other is that I'm worried the policies may
get large, and I'm not sure if it's a good idea to send relatively
large RAs regularly to all the nodes on a link.

Size could also be a problem for DHCP if people want to create very
complex policies.

Stig

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

---

From: [email-masked]
Date: Wed, 10 Aug 2005 18:29:50 +0900

Stig,

> Size could also be a problem for DHCP if people want to create very

Thank you for your clarification to the point.
Actually, we proposed both RA and DHCP options for
source address selection at first.
But we came to think that DHCP is more appropriate
for this purpose for the reasons you raised above.

Also, DHCP-Lite is stateless as you know, so it seems
to us that it is much easier to implement and to operate
for almost all the cases we suppose.

That is why we focus on DHCP option right now.

---

From: Greg Daley <[email-masked]>
Date: Thu, 11 Aug 2005 13:27:56 +1000

Dear Stig,

> multiple interfaces. This needs to be considered for both RAs and

It's unclear at the moment how a DHCP server on one link is able
to describe how to use addresses available on another interface
or link.

Particularly, it's not clear how the DHCP server can have authority
to modify the previously advertised address state from another link,
where it isn't responsible for configuration.

Given that the policy is based on per interface available addresses,
and the host will need to make a combination of these policies anyway,
there's little to be gained by assuming the DHCP server is all-knowing
about foreign addressing policies.

So I don't see the "per-host" argument as convincing at all.

> large RAs regularly to all the nodes on a link.

The Cost in RA is actually completely subsumed by the existing
advertisement of Prefix Information Options, which may be
augmented (without size modification) by identifying the
preference of the particular prefix, for source address
selection policies.

It is worth noting, that in the DHC proposal, 24 bits of data:
(label, precedence, zone-index) are added which aren't present
in PIOs.

There's an unused 32 octet field available (and another 5 unused
bits for flags) in each PIO, which are currently unused.

So there's no on-the-medium additional cost.

So the only issue is: Does it make sense to use RAs for distributing
the default source address preferences to hosts?

While it may seem to be a good idea to have different preferences
proposed for each host, it's not actually very useful.
Hosts can ignore or override the preferences, which is why
the policy is described as a default policy in the DHC draft.

Considering that the advertised Valid and Preferred Lifetime values
for prefixes are per prefix and not per-host, if we're providing
routability and stability information to hosts, then the information
should likewise be per prefix (not per host).

In that case, I guess that PIOs (in RAs) are a good place for them,
just like the Valid and Preferred Lifetimes.

If the mechanism is being used for some stealthy control of which hosts
should use which addresses on the link, I'm against it (since it's
unenforceable anyway).  I'm also against it if the policy is aimed
at being used as a load sharing mechanism (since there are better ways
of achieving this).

Greg

---

From: "timothy enos" <[email-masked]>
Date: Thu, 11 Aug 2005 01:40:30 -0400

Hi Greg/Stig,

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Greg Daley
> Sent: Wednesday, August 10, 2005 11:28 PM
> To: Stig Venaas
> Cc: [email-masked]
> Subject: Re: Solutions for distributing RFC 3484 address selection
> policies
> 
> Dear Stig,
> 
> Stig Venaas wrote:
> > get the same policy.

One thing is that in using DHCPv6, all DHCPv6 clients on the link will
get the same policy. Also, IMO it wouldn't always be bad for all hosts
on a link (DHCPv6 or otherwise) to get the same policy.

> The other is that I'm worried the policies may

Actually it's six unused bits in the Reserved1 field of the PIO, but
who's counting? :) 

In the case of flags, it would seem in most cases one bit per rule would
do (0=don't implement rule, 1=do implement rule... or something like
this). In the cases where there is an option to implement the reverse of
a rule (such as is required for rule #7 for source address selection (if
it is implemented)), it seems two bits would be needed (00=don't
implement this rule, 11=do implement this rule, 01=implement the reverse
of this rule... for example).

> should likewise be per prefix (not per host).

Agreed.
 
> just like the Valid and Preferred Lifetimes.

At least for setting prefix preference, yes RA PIOs are a good place for
them.

---

From: Greg Daley <[email-masked]>
Date: Thu, 11 Aug 2005 15:54:26 +1000

Hi Tim,

timothy enos wrote:
[cut]
> Actually it's six unused bits in the Reserved1 field of the PIO, but

Mobile IPv6  [ as referred previously: RFC3775, Section 7.2].

Greg

---

From: Stig Venaas <[email-masked]>
Date: Thu, 11 Aug 2005 12:05:39 +0200

Dear Greg,

> So I don't see the "per-host" argument as convincing at all.

It seems we are discussing very different things here. You are
talking of prioritizing the prefixes announced on the link(s) so that
the host can use these to influence source address selection, right?

In that case I agree that it makes sense to pass the priority along
with the prefixes of course.

The 3484 policy table however allows much more than that. It allows
destination address selection in which case you want to have some
preference among prefixes that are not prefixes for the link where
the client is. 3484 also allows preference of IPv4 vs IPv6. That
policy would be more awkward to pass in RAs, and isn't necessarily
for one particular link.

> preference of the particular prefix, for source address

For preference amongst the prefixes on the link, yes.

> (label, precedence, zone-index) are added which aren't present

But as I said, this does much more. E.g. the label is for destination
address selection. You're comparing apples and oranges here.

> the policy is described as a default policy in the DHC draft.

I'm sure there are different views on that. I would like a site
administrator to specify behaviour of the hosts in the site without
having to manage each host separately. So I want hosts generally to
use exactly the specified policy. This is also why I want to allow
for different hosts on a link to be told to have different policies.
Certainly there might still be ways for a host to override the
policy though.

> should likewise be per prefix (not per host).

For prefix preference which you're talking about I agree.

> at being used as a load sharing mechanism (since there are better ways

Neither of these are what I have in mind. For some possible uses of
3484, see http://www.nttv6.net/dass/

Might be good idea to discuss how to prioritize prefixes (and I assume
source address selection) and uses for that, independently of what 3484
can solve and how that can be used.

There is of course overlap. I would be interested to see how you want
your solution to work wrt source and destination address selection. Do
you imagine doing destination and interface selection first, and then
use this to pick source address? Or do you want this in some way to
influence destination address selection as well.

Stig

---

From: Ralph Droms <[email-masked]>
Date: Thu, 11 Aug 2005 10:03:57 -0400

On Thu, 2005-08-11 at 01:40 -0400, timothy enos wrote:
> [...]

It's not the case that all DHCPv6 clients on a link need to be
configured with the same policy; the DHCPv6 server can return a specific
(and potentially different) policy for each client.

- Ralph

---

From: Greg Daley <[email-masked]>
Date: Fri, 12 Aug 2005 10:14:51 +1000

Hi Ralph,

> (and potentially different) policy for each client.

I agree that this is possible, and may be valid.

Is this what people want to use the proposed option for, though?
Or are they just interested in providing an information service about
the advertised prefixes?

Greg

---

From: "timothy enos" <[email-masked]>
Date: Thu, 11 Aug 2005 22:31:56 -0400

Hi Ralph,

> From: Ralph Droms [mailto:[email-masked]]
> Sent: Thursday, August 11, 2005 10:04 AM
> To: timothy enos
> Cc: [email-masked]; 'Stig Venaas'; [email-masked]
> Subject: RE: Solutions for distributing RFC 3484 address selection
> policies
> 
> (and potentially different) policy for each client.***

Yes, I see that*** now, thanks. FWIW, I can see potential value for each
client on a link having the same RFC 3484 policy. I cannot see the
potential value of each (DHCPv6) client having a different policy.

---

From: "timothy enos" <[email-masked]>
Date: Thu, 11 Aug 2005 22:42:04 -0400

Hi Greg,

> From: Greg Daley [mailto:[email-masked]]
> Sent: Thursday, August 11, 2005 8:15 PM
> To: Ralph Droms
> Cc: timothy enos; 'Stig Venaas'; [email-masked]

Under what circumstances would this be preferable and/or recommended?
That any given configuration is valid (syntactically, and doesn't break
any RFC rules) doesn't mean it should be implemented.

> Or are they just interested in providing an information service about

Personally, I'd like to see the policy be more than just an information
service about the advertised prefixes.

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 12 Aug 2005 16:50:40 +0200

Hi Greg,

> Or are they just interested in providing an information service about

I guess that it also would make sense to provide label/preference 
information about destination prefixes/addresses i.e. not only 
providing information about the prefixes available in the link, but 
also about remote prefixes

Regards, marcelo