Subject: Distribution of RFC 3484 address selection policies

From: Stig Venaas <[email-masked]>
Date: Mon, 8 Aug 2005 21:44:27 +0200

RFC 3484, and implementations thereof, allows for a sysadmin to
configure address selection policy on a single host. I think this is
useful, and I suppose also the wg since the RFC was published. One
typical example might be preferring IPv4 over IPv6.

If I as a site administrator want all the hosts at my site to prefer
IPv4 over IPv6, I need to distribute that policy to all of them. I
hope you can understand the need for that. In that case, I think we
should try to look for possible solutions. Some applications might
want to specify their own particular behaviour, but I see several
reasons why an administrator may want to specify a default.

Using DHCP may be one solution. The only alternative available today,
is to log into every single host and run each host's OS specific
commands to change the policy. This might work for hosts that are
centrally administrated at that site. It would not work for hosts
visiting that network or under different management.

Do you agree this is something that should be solved? It's probably
a good idea to discuss that before going into particular solutions.

Stig

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

---

From: Fred Baker <[email-masked]>
Date: Mon, 8 Aug 2005 13:16:32 -0700

personally, I an see a *lot* of reasons to leave such decisions in  
the hand of the administration. The most compelling is: "try taking  
it out of the administration's hands. Just try. I dare ya."

DHCP/DHCPv6 seems like a reasonable choice of dynamic host  
configuration protocol.

---

From: "Mark K. Thompson" <[email-masked]>
Date: Mon, 8 Aug 2005 21:40:06 +0100

> DHCP/DHCPv6 seems like a reasonable choice of dynamic host  

Naturally I concur, however two technical challenges leap out at me  
concerning the nature of the policy table as specified by RFC3484.

First, the lack of field definition for labels has seen different  
OSes use different datatypes for the label, from string through  
stringified-integer to integer. Any cross-platform policy  
specification protocol would need to cater for this inconsistency.  
Perhaps this is something that a RFC3484-bis could address when  
making that spec compliant with the requirements of RFC3879 Section 4?

Also, RFC3484 permits the specification of zone index in the policy  
(c.f section 2.1). Section 6 of RFC4007 explicitly states that zone  
indices are strictly local to the node, making any centralisation of  
RFC3484 policy "challenging". [aside: OK, so administrators could  
harvest index data for links on which scoped-policy is required and  
then maintained in the DHCPv6 server as specific for that node, but  
there's no protocol for that harvesting and I've not surveyed  
sufficient implementations to determine whether indexes persist and  
are consistent between reboots]

So, yes, I agree that centralisation of address selection of policy  
is important (and necessary for folks using ULAs with greater-than- 
site scope multicast), and that DHCPv6 appears a reasonable choice,  
but there are fundamental issues with RFC3484 that need to be  
addressed at the outset.

Mark/

--
Dr Mark K. Thompson
Electronics and Computer Science
a School of the University of Southampton, UK

---

From: Greg Daley <[email-masked]>
Date: Tue, 09 Aug 2005 09:58:06 +1000

Hi Mark,

Mark K. Thompson wrote:
[cut]
> 
> So, yes, I agree that centralisation of address selection of policy  is 
> important (and necessary for folks using ULAs with greater-than- site 
> scope multicast), and that DHCPv6 appears a reasonable choice,  but 
> there are fundamental issues with RFC3484 that need to be  addressed at 
> the outset.

I mentioned in the DHC session that prefix and routing configuration
decisions in IPv6 typically aren't controlled through DHC.

They are controlled through router discovery (RFC2461).  More specific
routes and router selection are also performed by modifications to
ND Router Advertisement messages.

I therefore don't think it is a good fit to proceed with DHC options
for the purpose of source address selection default policy.

So I think I agree with you, that determination whether
centralized control is valid needs to occur, before delving into
solutions (solution looking for problems was heard in that session).

Greg

---

From: Fred Baker <[email-masked]>
Date: Mon, 8 Aug 2005 17:34:13 -0700

how do the routers (which control router discovery) get this policy  
information?

On Aug 8, 2005, at 4:58 PM, Greg Daley wrote:

> Hi Mark,
>
> Mark K. Thompson wrote:
> [cut]
>
>> So, yes, I agree that centralisation of address selection of  
>> policy  is important (and necessary for folks using ULAs with  
>> greater-than- site scope multicast), and that DHCPv6 appears a  
>> reasonable choice,  but there are fundamental issues with RFC3484  
>> that need to be  addressed at the outset.
>>
>

---

From: Greg Daley <[email-masked]>
Date: Tue, 09 Aug 2005 12:24:51 +1000

Hi Fred,

> how do the routers (which control router discovery) get this policy  

There's no existing mechanism for describing the source address
selection policies using router discovery.

For router discovery itself though, the configured IPv6
prefixes are typically configured through configuration files.
I'd guess there are proprietary MIBs to describe this as well.

I'm not sure anyone is doing it, but renumbering is applicable
there as a means of providing information about which prefixes
are valid.

I'd guess that any mechanism which interacted with router discovery
to provide address selection policy would need to be integrated with
the ND messages, and the configuration systems applicable to those
messages.

Greg.

---

From: Arifumi Matsumoto <[email-masked]>
Date: Tue, 9 Aug 2005 19:53:22 +0900

Mark,

On 2005/08/09, at 5:40, Mark K. Thompson wrote:

>> personally, I an see a *lot* of reasons to leave such decisions in the hand of the administration. The most compelling is: "try taking it out of the administration's hands. Just try. I dare ya."
>>
>> DHCP/DHCPv6 seems like a reasonable choice of dynamic host configuration protocol.
>>
>
> Naturally I concur, however two technical challenges leap out at me concerning the nature of the policy table as specified by RFC3484.
>
> First, the lack of field definition for labels has seen different OSes use different datatypes for the label, from string through stringified-integer to integer. Any cross-platform policy specification protocol would need to cater for this inconsistency. Perhaps this is something that a RFC3484-bis could address when making that spec compliant with the requirements of RFC3879 Section 4?

let me comment one thing.
By our protocol, we intend to distribute an address selection policy,
of course, but the values in this option aren't absolute but relative.
When an option includes the following, for example:

Prefix        Precedence  Label
2001:db8::/48        100     10
3ffe:db8::/48         20     10
2002:1:2::/48         10      5

The Label values just indicate that the first line and the second line
has the same label and the third line doesn't have the same label as
any other lines.
This is the case with Precedence value. This option indicates the order
of precedence.

So, if a host has its policy table configured manually and has the label
value 10, the distributed policy's label value should be changed to
another un-used value or string.

About Precedence, the values in distributed option can be changed
as far as the order isn't changed.

So, this just seems to me an issue of implementation on DHCPv6 option
receiver. It may be better to clarify these implementation considerations
in our draft or in another draft.

>
> Also, RFC3484 permits the specification of zone index in the policy (c.f section 2.1). Section 6 of RFC4007 explicitly states that zone indices are strictly local to the node, making any centralisation of RFC3484 policy "challenging". [aside: OK, so administrators could harvest index data for links on which scoped-policy is required and then maintained in the DHCPv6 server as specific for that node, but there's no protocol for that harvesting and I've not surveyed sufficient implementations to determine whether indexes persist and are consistent between reboots]

Actually, we aren't sure that this field is necessary.
We also have never heard a case harvesting it.
As you mention it, this value is local in a node,
so there may be no use to distribute it in a centralized
manner.

--
Arifumi Matsumoto <[email-masked]>

---

From: Fred Baker <[email-masked]>
Date: Tue, 9 Aug 2005 09:32:35 -0700

On Aug 8, 2005, at 7:24 PM, Greg Daley wrote:
> there as a means of providing information about which prefixes are  
> valid.

One of the outcomes of the v6ops WG last week was the observation  
that the Router Renumbering Protocol is not widely implemented, and  
when renumbering-in-anger persuant to

   http://www.ietf.org/internet-drafts/draft-ietf-v6ops-renumbering- 
procedure-05.txt
   "Procedures for Renumbering an IPv6 Network without a Flag Day",  
Fred Baker,
   18-Mar-05, <draft-ietf-v6ops-renumbering-procedure-05.txt>

was tested by the 6net folks, it was found wanting in a variety of  
ways. Basically, it made the special case where you want to  
distribute a new aggregated prefix and maintain the same subnet  
number distribution (such as "I have changed upstream provider")  
pretty simple, but didn't cover any of the other cases in which one  
might want to renumber, and didn't handle any of the nuances like  
making sure this also happened in route maps, aggregation filters,  
qos classification filters, etc.

As the discussion proceeded, we basically decided that renumbering  
(and more generally number distribution and number use policy) was  
the province of the network management folks, perhaps netconf. They  
need to decide how to manage a network, and if a protocol like RRP is  
part of that, specify a set of requirements for it. RRP at minimum  
needs work, and I would suggest it be declared "historic" and  
replaced with a new protocol if such a definition happens.

---

From: Greg Daley <[email-masked]>
Date: Wed, 10 Aug 2005 13:51:19 +1000

Hi Fred.

Fred Baker wrote:
>> I'm not sure anyone is doing it, but renumbering is applicable  there 
>> as a means of providing information about which prefixes are  valid.
> 
> 
> One of the outcomes of the v6ops WG last week was the observation  that 
> the Router Renumbering Protocol is not widely implemented, and  when 
> renumbering-in-anger persuant to
> 
>   "Procedures for Renumbering an IPv6 Network without a Flag Day",  Fred 
> Baker,
> ways. Basically, it made the special case where you want to  distribute 
> a new aggregated prefix and maintain the same subnet  number 
> distribution (such as "I have changed upstream provider")  pretty 
> simple, but didn't cover any of the other cases in which one  might want 
> to renumber, and didn't handle any of the nuances like  making sure this 
> also happened in route maps, aggregation filters,  qos classification 
> filters, etc.
> 
> As the discussion proceeded, we basically decided that renumbering  (and 
> more generally number distribution and number use policy) was  the 
> province of the network management folks, perhaps netconf. They  need to 
> decide how to manage a network, and if a protocol like RRP is  part of 
> that, specify a set of requirements for it. RRP at minimum  needs work, 
> and I would suggest it be declared "historic" and  replaced with a new 
> protocol if such a definition happens.

Sure.   I guess that if automated generation of policy mappings for
source address selection are required then it would be useful to
work on this in concert with the main thrust of network management.

Moving RRP to Historic may leave questions unanswered in peoples'
heads regarding the ISP change scenario, but I really think moving the
focus to SHIM6 (which provides host-to-host survivability of
renumbering events) may actually be the better course (Shim6 people can
take aim now).

What's reasonable here with regard to address usage is to provide
indications of the network's perception of differences between addresses
to hosts.   The actual task of managing the network's perception
isn't really any different in DHCPv6 or Router Discovery (it's either
automated or manual).  The hosts receiving the default policy aren't
ever aware of the mechanism used.

As you mention, RRP may not be a valid way to do this configuration
today (or in future), but config files, SNMP and misuses of RADIUS
(not actually recommended) may be.

Greg

---

From: "timothy enos" <[email-masked]>
Date: Wed, 10 Aug 2005 00:00:55 -0400

Greetings all,

I believe it is better to update RFC 3484, as well as decide how to best
distribute address selection policies derived there from. Speaking of
source address selection, note that in section 3.1:

	'Use of the source address selection algorithm in the presence
of 	multicast destination addresses requires the comparison of a
unicast 	address scope with a multicast address scope... we map
unicast site-	local to multicast site-local... For example, unicast
site-local is 	equal to multicast site-local... This mapping implicitly
conflates 
	unicast site boundaries and multicast site boundaries'

Unicast site-local addresses were formally deprecated in RFC 3879.
Presuming the concept of site for multicast to be well enough defined so
as to not be deprecated, it doesn't seem logical to still conflate it
with something that has been. At the very least, this is the case with
new implementations (as in initial implementation being post-RFC 3879).
Regarding destination address selection, please note in section 3.2:
	
	'IPv4 private addresses... are assigned site-local scope.'

These are unicast addresses, for which the ill-defined (concept of)
site-local has been deprecated. In a post-RFC 3879 implementation, this
also seems illogical.
Continuing on to section 4, regarding candidate source addresses:

	'For site-local destination addresses, the set of candidate
source 	addresses MUST only include addresses assigned to interfaces
belonging 	to the same site as the outgoing interface.'

Given RFC 3879, there is no compelling case for what constitutes a site
in the unicast address space. Therefore, we seemingly cannot meet the
aforementioned MUST condition. (Yes, I know that site-local multicast
addresses have not been deprecated.) Moving on to section 5 (source
address selection), it is possible that a site-local unicast address
could be chosen by Rule 2. In section 6 (destination address selection),
Rule 2 is more definitive (a site-local unicast address could be chosen
here as well).

RFC 4007 seems to bolster the argument for updating of RFC 3484, given
RFC 3879. See section 1:

	'Though the current address architecture specification [1]
defines
   	unicast site-local addresses, the IPv6 working group decided to
   	deprecate the syntax and the usage [5] and is now investigating
other
   	forms of local IPv6 addressing.'

Since both the syntax and the usage of unicast site-local addresses has
been deprecated, this is a case for updating RFC 3484 (RFC 3513 is about
to be updated: see draft-ietf-ipv6-addr-arch-v4-04.txt). Please also
note the beginning of section 10 (routing):

	'Note that as unicast site-local addresses are deprecated, and
link-
	local addresses do not need routing, the discussion in this
section
   	only applies to multicast scoped routing.'

It is difficult to route to/through something that effectively no longer
exists. There is also the matter of IPv4-compatible addresses being
deprecated (draft-ietf-ipv6-addr-arch-v4-04.txt is in the RFC Editor
queue; section 2.5.5.1 of this document delineates the deprecation).

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Stig Venaas
> Sent: Monday, August 08, 2005 3:44 PM
> To: [email-masked]
> Subject: Distribution of RFC 3484 address selection policies
> 
> hope you can understand the need for that. 

Yes.

> In that case, I think we

A possibility for the future (realizing it does not presently exist)
seems to be the creation of a new Router Advertisement option. This
could be something that would be received and used by clients of both
DHCPv6 and SLAC.

Using DHCP to distribute RFC 3484 address selection policies would seem
to work for DHCP clients, yet not for SLAC clients.

> 
> Do you agree this is something that should be solved?

Yes.

> It's probably

Best regards,

Tim Enos
1Sam16:7

---

From: Greg Daley <[email-masked]>
Date: Wed, 10 Aug 2005 17:24:23 +1000

Hi Tim,

timothy enos wrote:
[cut]
> to work for DHCP clients, yet not for SLAC clients.

I'd guess that it may not be necessary to define a new ND option to
manage the preferences of prefixes, as there are 37 bits unallocated
in the Prefix Information Option (32 bit Reserved2 field + remnant of
Reserved1 field) [RFC3775 S7.2,RFC2461 S4.6.2].

I'd suggest that if preferences are all that's needed, then the
function matches that for which the options are used now.

Greg

---

From: Stig Venaas <[email-masked]>
Date: Wed, 10 Aug 2005 10:23:46 +0200

On Wed, Aug 10, 2005 at 05:24:23PM +1000, Greg Daley wrote:
[...]
> function matches that for which the options are used now.

I agree that if only prefix preference is needed (possibly also
v4 vs v6), then it seems obvious to learn this together with the
prefixes themselves. I.e. if you use slaac, then also get the
preference that way (similarly with dhcp or other mechanisms).
The preference is for destination address selection, right?

So a question then is whether that is enough or if there are
many cases where the full policy (including source address
selection) is needed. If the full policy is needed in some cases,
then we have to consider whether it's worth having two solutions.

I don't know myself, I think it requires further study.

Stig

---

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

> I don't know myself, I think it requires further study.

I myself think that full policy is needed, of course.

But, even if you define a option only for prefix *preference*
for this framework of policy table, I wonder what the label
value should be.

As for IPv4 and IPv6 selection, even if you choose an arbitrary
label value, it doesn't have any effects on source address selection.
But, once that option is used for multiple IPv6 prefixes,
the label value has some effects on source address selection also.

So, as far as you use the policy table framework as it is,
IMHO, you have to distribute prefix preference with label value.

---

From: "Mark K. Thompson" <[email-masked]>
Date: Wed, 10 Aug 2005 10:36:03 +0100

Hi,

On 9 Aug 2005, at 11:53, Arifumi Matsumoto wrote:
>> the lack of field definition for labels has seen different OSes  
>> use different datatypes for the label, from string through  
>> specification protocol would need to cater for this inconsistency
>

This strikes me as quite non-deterministic and I wonder whether  
administrators would be happy having pushed-policy being interpreted  
differently on different nodes depending on their individual state at  
the point where the policy was received.

For example, I can envisage scenarios where administrators want to  
assert precise control over the contents of the policy table  
exclusively over any local settings - and that policy may be node- 
specific as determined by DUID or some Vendor option in DHC.  
(Assuming that a DHC approach was deemed suitable)

Mark/

---

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

Hi

[email-masked] wrote:
[cut]
> IMHO, you have to distribute prefix preference with label value.

It's actually really disappointing that the label field is
completely undescribed and (from section 5)

"... clients need to convert this label to a representation
specified by each implementation (e.g., string)."

This is asking for incompatability, and doesn't serve any
useful purpose in standardization.

Particularly, there's no identification of _which_ implementation
the DHCP server intends, especially if it is not aware of the
current code version or OS on the host.

Perhaps this should be vendor specific information if used in DHC?

I can't see any use for it now, and it would need to be strictly
specified before providing use any clients.

Greg

---

From: "timothy enos" <[email-masked]>
Date: Wed, 10 Aug 2005 23:37:35 -0400

Hi Greg,

> From: Greg Daley [mailto:[email-masked]]
> Sent: Wednesday, August 10, 2005 3:24 AM
> To: timothy enos
> Cc: 'Stig Venaas'; [email-masked]
> Subject: Re: Distribution of RFC 3484 address selection policies
> 
> Hi Tim,
> 
> timothy enos wrote:
> [cut]
> >>In that case, I think we
> Reserved1 field) [RFC3775 S7.2, RFC2461 S4.6.2].

Good point Greg. The 38 unallocated bits spread over the two Reserved
fields would seem to be sufficient. I was taking the admittedly somewhat
narrow view that the Prefix Information Option was only meant to specify
on-link prefixes and/or those that are meant to be used for
autoconfiguration (RFC 2461, 4.2). Either using the heretofore unused
bits in the Prefix Information Option, or the creation of another option
(say, 'Address Selection Option') would be fine with me.

> function matches that for which the options are used now.

Are preferences all that are needed here? It seems that the question of
how hosts would handle such an option also needs to be answered. 

> Greg

Tim
1Sam16:7

---

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

Hi Mark,

Mark K. Thompson wrote:
>>> the lack of field definition for labels has seen different OSes  use 
>>> different datatypes for the label, from string through  
> specific as determined by DUID or some Vendor option in DHC.  (Assuming 
> that a DHC approach was deemed suitable)

I can't see this as particularly useful, and there are better ways
(for example PANA address assignment or VPNs) to tie this to the
access control state of the host.

Otherwise, the control is superficial.  Hosts or applications
can ignore or reject the advice of the server, and configure what
they like.

Greg

---

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

Hi Stig,

> From: Stig Venaas [mailto:[email-masked]]
> Sent: Wednesday, August 10, 2005 4:24 AM
> To: Greg Daley
> Cc: timothy enos; [email-masked]
> prefixes themselves. 

I don't believe that only prefix preference is needed. For mobile nodes,
both for source and destination address selection there is home
vis-à-vis care-of addresses (rule #4). Perhaps also given RFC 3041
section 2.3, source address rule #7 (either to prefer public or
temporary) would be needed.

For all nodes, it seems that source address selection rule #2 is
required:

	'Rule 2 (prefer appropriate scope) MUST be implemented
	and given high priority because it can affect interop-
	erability.' (RFC 3484, section 5)	

> I.e. if you use slaac, then also get the
> selection) is needed.

I wouldn't agree that all source address selection rules should always
be excised from what is distributed. 

> If the full policy is needed in some cases,

IMO, it doesn't seem necessary to have two solutions, if what is meant
by that is to have one for SLAC clients and another for DHCPv6 clients.
Using RAs could probably work for both types of clients.
 
> I don't know myself, I think it requires further study.

Agreed.

Best regards,

Tim
1Sam16:7

---

From: Tim Chown <[email-masked]>
Date: Thu, 11 Aug 2005 12:21:52 +0100

> there as a means of providing information about which prefixes

We went through a pretty full enterprise renumbering procedure, but were
able to control address selection purely through RAs, to indicate the
deprecated status where multiple prefixes were advertised.   This worked
well - address selection was correct on XP, Linux, MacOS and Solaris.
Purely for renumbering, RA indications may suffice.   There is however,
much greater complexity to managing a renumbering event, as Fred described.
 
> the ND messages, and the configuration systems applicable to those

There's a few comments I'd make on this (very interesting) thread.

It is important that we consider source and destination address selection,
i.e. full 3484 policy.   We also need to support non-prefix based policy,
like whether privacy addresses should be used.  As an enterprise admin,
I see 3041 as adding a lot of management complexity for little gain (though
as a roaming IPv6 user, my view is different :).  I don't think the suggested
method off 'adding the /128 into the table' cuts it.   We also probably would
like v4 vs v6 preference too.   This has to be done in the knowledge that
applications may be trying to make their own choices via APIs here.

As an admin, I like DHC as a proposed solution.  We've already seen pushback
on bloating RAs, e.g. for DNS resolver discovery.   I think the DHC-based
draft is flawed if it is adding policy not replacing policy - especially
where new 'random' labels are being generated where clashes exist.  I would
like an absolute policy distribution.   Greg points out that the hosts may
ignore it, but the hosts can ignore allocated addresses too the way many
enterprises are run :)

I thinka DHC server offlink can give the information... relay agents can
handle that?  I'd rather have policy configured in one DHC service, or did
I misunderstand?

Having a per host policy capability would be nice.

Tim

---

From: Ralph Droms <[email-masked]>
Date: Thu, 11 Aug 2005 09:06:40 -0400

Seems to me the WG ought to work through these questions:

1. Is RFC 3484 adequate to solve the address selection problem?

My guess is "no", because of its references to site-local addresses and
other deficiencies discussed in this thread.  If the answer is no, the
first step for the WG would be to update RFC 3484.

2. Is there a requirement for automated/administered management of the
address selection policy specified in RFC 3484 (or RFC 3484bis) in
hosts?

Seems like there is enough interest in this thread for policy management
to warrant WG activity...

3. What are the right semantics and the right vehicle for providing
management?

TBD, once we get answers to 1 and 2?

- Ralph

---

From: Tim Chown <[email-masked]>
Date: Thu, 11 Aug 2005 15:18:33 +0100

> first step for the WG would be to update RFC 3484.

Rich seemed amenable to this when asked recently.  In doing so, we
should review default policy to minimise the requirement to change
policy, e.g. fix the corner cases like ULAs+multicast being broken.

-- 
Tim/::1

---

From: Stig Venaas <[email-masked]>
Date: Thu, 11 Aug 2005 16:51:07 +0200

> policy, e.g. fix the corner cases like ULAs+multicast being broken.

Also worth checking if there are address selection problems that 3484
doesn't address.

Stig

---

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

- Ralph

---

From: Tim Chown <[email-masked]>
Date: Thu, 11 Aug 2005 15:59:11 +0100

> Also worth checking if there are address selection problems that 3484

Like selecting privacy addresses?

-- 
Tim/::1

---

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

> Like selecting privacy addresses?

My feeling is that it's sufficient to disable/enable. Or is there
really a need for using privacy source addresses for some destinations
and not others?

I think it's good if the policy is a bit generic, i.e. avoiding
literal naming of the hosts addresses (possibly prefixes) when
possible. I don't how it could be done, but some solution that means
the policy is valid independent of which particular prefixes are on a
link at a given time (and what privacy addresses the host has).

Maybe helps to use some sort of tokens in the policy? Something like
LINK_PREFIXES, MY_PRIVATE_ADDRESSES, MY_PUBLIC_ADDRESSES,
MY_ULA_ADDRESSES. But again, I don't really know if it could work,
and if it's work doing. I think it's something to consider though.

Stig

---

From: "timothy enos" <[email-masked]>
Date: Fri, 12 Aug 2005 01:02:00 -0400

Hi Ralph,

Of
> Ralph Droms
> Sent: Thursday, August 11, 2005 9:07 AM
> To: IETF IPv6 Mailing List

I for one believe RFC 3484 needs to be updated, largely because of all
of the references to site-local unicast addresses. Presuming its
deficiencies are deemed significant enough to warrant its updating, it
seems we have a case for doing so even before we decide how to
distribute it. 

Agreed.