Stig Venaas wrote:
On Thu, Jun 23, 2005 at 10:46:44AM -0400, Vlad Yasevich wrote:

On Thu, 2005-06-23 at 16:09 +0200, Stig Venaas wrote:

On Thu, Jun 23, 2005 at 10:03:36AM -0400, Vlad Yasevich wrote:

Tim

Wouldn't an update to a policy table be enough to resolve the problem?

Yes, but isn't it best that the default policy does the right thing?


I agree. Is this something that may be mentioned in ULA spec?


Too late I think, it's already in rfc ed queue. However 3484 should be
updated anyway to remove site-locals and something about ULA could then
be added. This would be a trivial change.

Yes, the problem is in 3484, so let's fix 3484 rather than further delay
ULAs.


Note that the ULA draft, draft-ietf-ipv6-unique-local-addr-09.txt is
vague regarding scopes:

      - In practice, applications may treat these addresses like global
        scoped addresses.

which I think is wrong if host also has normal global unicast
addresses. But wording indicates that they are not really global
scoped addresses.

No it doesn't. It's a lower case "may" not a normative MAY - it means
in plain English exactly what it says.


Also

3.3 Scope Definition

   By default, the scope of these addresses is global.  That is, they
   are not limited by ambiguity like the site-local addresses defined in
   [ADDARCH].  Rather, these prefixes are globally unique, and as such,
   their applicability is greater than site-local addresses.  Their
   limitation is in the routability of the prefixes, which is limited to
   a site and any explicit routing agreements with other sites to
   propagate them (also see section 4.1).  Also, unlike site-locals, a
   site may have more than one of these prefixes and use them at the
   same time.

What does default mean here?

It might have been better to remove the words "By default."  The reality
is that they are scoped by the routing setup, not by a formal scope.
And so they could only be used for sourcing multicasts that will be
similarly scoped by the routing setup. Clearly, 3484 defaults can't deal
with that.

  Brian


Stig


Else everyone with ULA doing global multicast will need to update their
policies. Of course vendors could use their own default policy that is
different from 3484's policy...

Yes.  I've always considered policy from 3484 an example that will be
modified by the end-user.  That's why it's there.  It gives a really
basic default.  If you want to be multiaddresses with ULA and global
prefixes, you need to tweak things.

-vlad




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

Reply via email to