On Thu, 2005-08-11 at 16:51 +0200, Stig Venaas wrote:
> On Thu, Aug 11, 2005 at 03:18:33PM +0100, Tim Chown wrote:
> > On Thu, Aug 11, 2005 at 09:06:40AM -0400, Ralph Droms wrote:
> > > 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.
> > 
> > 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.
> 
> Also worth checking if there are address selection problems that 3484
> doesn't address.
> 
> Stig

Mark Thompson pointed out:


> 
> 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]

- Ralph


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

Reply via email to