Subject: Unicast and multicast site-local addresses

From: "Barany, Pete" <[email-masked]>
Date: Wed, 15 Oct 2003 09:38:23 -0700

Hi,

Question: How does the deprecation of site-local unicast addresses (as
defined in RFC 3513 Section 2.5.6) impact/affect site-local multicast
addresses (as defined in RFC 3513 Section 2.7)? For example, setting the
4-bit "scop" field to a value = 5 limits the scope of a multicast group
to "site-local scope". One usage defined by DHCPv6 is for a Relay Agent
to send a RELAY-FORW message to All_DHCP_Servers site-local scope
multicast address (FF05::1:3) if it is not pre-configured with the IPv6
address(es) of DHCPv6 server(s).

Regards,

Pete

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

---

From: Brian Haberman <[email-masked]>
Date: Wed, 15 Oct 2003 12:45:38 -0400

Hi Pete,
      The deprecation document only applies to site-local unicast
addresses.  I pointed out in SF that we still have to deal with the
scoped multicast addresses.  That is one of the goals of the modified
Scoped Addressing Architecture document.

      There has been some discussion on the ipv6 list and several of the
multicast lists about the behavior that is needed with regards to
multicast forwarding/routing.  Hopefully, all of those issues have or
will be addressed in the scoped addr architecture doc.

Brian

---

From: Andrew White <[email-masked]>
Date: Thu, 16 Oct 2003 16:55:35 +1000

I'm not sure we want to throw out the idea of 'scope'.  Even without SL, two
scopes are architecturally enshrined in IPv6, link-local (addresses are
valid and unique only on-link) and global (addresses are globally unique).

You'll notice that I don't say addresses are globally valid.  Architectural
scope talks about uniqueness.  Functional scope talks about where an address
is actually useable - the presence of filters and the such mean that there
are many situations where an address is unique but wont work.  This is a
feature, not a flaw.

The problem with SL and scope were twofold, and both were about
non-uniqueness.  A single SL address space is robust, even if nested within
a larger global address space, as long as the address selection algorithms
have a mechanism for evaluating scope and choosing an appropriate address.

However, there is no guarantee of uniqueness between SL spaces, which
creates problems on merge.  Worse, SL allowed non-unique spaces to overlap
and required an additional 'scope identifier' to determine which space an
address belonged to.  This scope identifier became a piece of addressing
information that was no included in the address, with obvious problems.

Given that we have a mechanism for solving the uniqueness problem (see note
1), then I think scope is a healthy concept.  At least for address
selection, its not that hard to encode certain scopes to certain address
ranges and have address selection respond accordingly.  Dealing with scope
in a more general sense (eg I know this address - is it valid in any of my
scopes?) is a knottier problem, but that problem exists regardless of
whether scopes are defined.  Having a mechanism to map an address to a scope
makes the above problem easier.

Note 1:  Link local and the proposed local addressing draft both propose
mechanism to cause the addresses generated to be unique, even outside their
scope.  LL uses the MAC address, while local addressing uses either
allocation or randomization.

-- 
Andrew White