Subject: ULAs, multicast and RFC3484 issue?

From: Tim Chown <[email-masked]>
Date: Thu, 23 Jun 2005 12:43:23 +0100

Hi,

As part of our studies in IPv6 renumbering(*) in the 6NET project we've
been looking at running ULAs alongside globals for internal communication
stability through a renumbering event.

We seem to have hit an issue with ULAs and multicast, that we'd like to
get WG comment on.

When a node is multiaddressed with ULA and global prefixes, and wishes
to send to a globally scoped multicast group,  RFC3484 policy will select
the best match source address of equal scope.   The 'snag' is that, as 
per section 3.3 of the ULA draft, ULAs are global scope.  As a result,
multicast traffic to global scope groups will be sent with ULA source 
addresses.

We note that RFC 3879 on site local deprecation doesn't mention multicast,
we suspect because the deprecation text was written pre-ULAs.

RFC 3484 talks of scope comparisons in section 3.1, but the language of
'site locals' is now out of date.

So, if this is an issue, should it be fixed by a recall of ULAs from the
RFC editor's queue, or an update to RFC 3484?   It seems a 3484 update
is needed at some point due to the 'site local' references in it.

Comments?

-- 
Tim/::1

(*) See: http://www.6net.org/publications/deliverables/D3.6.1.pdf
    and http://www.6net.org/publications/deliverables/D3.6.2.pdf

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

---

From: Mark Smith <[email-masked]>
Date: Thu, 23 Jun 2005 21:51:51 +0930

Hi Tim,

On Thu, 23 Jun 2005 12:43:23 +0100

> is needed at some point due to the 'site local' references in it.

Sorry not to address your question specifically, however I think there
might be a similar issue regarding using host routes and multicast,
which may also necessitate an update to RFC3484. Using host routes has
been proposed as a method of topology hiding in one of the v6ops drafts
(the NAP one). I don't want to thread-jack any discussion on your issue,
I've changed the topic so hopefully they can be split and discussed
separately if necessary.

Here is what I think the issue is. If the end-node has a link-local
prefix, and a /128 prefix-length ULA or global address, and it wants to
perform a link-local scoped multicast on a broadcast multi-access link,
I think the following would occur :

(a) if the source address of the link-local scoped multicast isn't
selected, then RFC3484 would mean that the nodes link-local address
would be used as the multicast source address. All good.

(b) if the source address of the link-local scoped multicast was
selected as the /128 ULA or global address, to where is the
multicast actually sent ? I can think of a couple of options :

- A /128 prefix length in routing terms indicates that everything else
is offlink. Should the multicast be dropped, as there is no other onlink
destinations for link-local scoped multicasts to go to ? Alternatively,
at the IPv6 layer, with this /128 prefix length, this node's
relationship with the routers is similar to the node having individual
point-to-point links to the routers it has learned of via RAs, even
though the underlying layer 2 link technology is broadcast multi-access.
Should the multicast be sent to the routers it has learned of through
RAs, possibly using unicast link layer destinations  to ensure other
routers don't receive this multicast (obviously the node has to
replicate the packet to do this) ?

- Alternatively, the view could be that the node should only send the
multicast to nodes that it knows it is attached to directly at layer 2.
There is also some abiguity here. Does this mean :

o only the routers it has learned of via RAs.

o the routers it has learned of via RAs, as well as nodes that it has
learned are layer 2 peers via ICMP redirects

In either of these cases, the node may need to be selective as to which
of it's layer 2 peers it sends the multicast to, which possibly means
unicasting at layer 2 the multicast to the selected peers.

Regards,
Mark.

---

From: Mark Smith <[email-masked]>
Date: Thu, 23 Jun 2005 22:45:40 +0930

On Thu, 23 Jun 2005 21:51:51 +0930
Mark Smith <[email-masked]> wrote:

<snip>

> I think the following would occur :

Hmm, the multicast link-local issue I described might not be an issue,
as it seems that according to draft-ietf-ipv6-addr-arch-v4-04.txt the
interface id must be 64 bits in size, indicating that a /128 would be
invalid on the nodes interface, although valid in an upstream router's
route table.

I'll have to do a bit more thinking as to how host routing would work
from an end-nodes point of view, when trying to achieve topology hiding
or rather subnet hiding from nodes located outside the assigned local
/48(s).

Sorry for the noise,
Mark.

---

From: Vlad Yasevich <[email-masked]>
Date: Thu, 23 Jun 2005 10:03:36 -0400

Tim

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

-vlad

---

From: Stig Venaas <[email-masked]>
Date: Thu, 23 Jun 2005 16:09:47 +0200

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

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

Stig

---

From: "Mark K. Thompson" <[email-masked]>
Date: Thu, 23 Jun 2005 15:15:05 +0100

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

It's more than one update, I think:

     If the candidate destination address is from a fc00::/7 prefix  
in the set that are either local to this network or a prefix at a  
network with whom I have routing agreements, then prefer a local ULA  
source address; otherwise if the candidate destination address is  
from any other fc00::/7 prefix, never prefer our ULA source address

Perhaps the second clause is not necessary where the first rules bump  
local ULAs up the preferred source address list (one rule per  
routable fc00::/7 prefix)

I can see a straw poll of 3484 implementations on the horizon...

Mark/

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

---

From: Vlad Yasevich <[email-masked]>
Date: Thu, 23 Jun 2005 10:46:44 -0400

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

> 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

---

From: Vlad Yasevich <[email-masked]>
Date: Thu, 23 Jun 2005 10:49:57 -0400

> It's more than one update, I think:

My point was more that an update (or updates) to the policy table would
solve this.  I guess the number of updates depends on how the policy is
implemented.

You could always prefer global over ULA for multicast, and will fall
back to ULAs only if all global prefixes are deprecated.  This is
really and end-user decision.

-vlad

---

From: Mark Smith <[email-masked]>
Date: Fri, 24 Jun 2005 00:23:17 +0930

On Thu, 23 Jun 2005 10:46:44 -0400

> prefixes, you need to tweak things.

I'd think ULAs and globals deployed in parallel would be the most common
case, so I'd think it should just work "out of the box" without having
to tweak anything. Without putting a bit of effort into it i.e. off the
top of my head, I can't think of scenarios where ULAs wouldn't be
deployed in parallel with globals.

Regards,
Mark.

---

From: Stig Venaas <[email-masked]>
Date: Thu, 23 Jun 2005 17:02:01 +0200

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

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.

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?

Stig

---

From: "Mark K. Thompson" <[email-masked]>
Date: Thu, 23 Jun 2005 16:50:12 +0100

On 23 Jun 2005, at 15:53, Mark Smith wrote:

>> I've always considered policy from 3484 an example that will be

But for sure there are basic policies that could (should?) be enabled  
by default so that ULAs aren't preferred as source addresses for  
anything other than potential ULA destinations (e.g. due to sites  
misbehaving by putting ULAs in global DNS RRs)

I'm rapidly coming to the same conclusion as Fred :-/

The use of site locals (sorry - i'll pay penance later) and, after  
FEC0's deprecation,  ULAs that we have motivation for is disconnected  
networks that have topology - principally sensor nets and such beasts  
as community wireless networks.  Both of these application domains  
have a requirement for provider independent addressing or survivable,  
swift and automated renumbering that requires little to no  
administrator intervention. The latter hurts my head, even after  
working on an IPv6 Renumbering project ;-)

> to tweak anything.

Absolutely.

> Without putting a bit of effort into it i.e. off the

Either scenario above can start out as just ULA with potentially  
ephemeral and variable availability of globals.

Mark/

---

From: Tim Chown <[email-masked]>
Date: Thu, 23 Jun 2005 17:03:42 +0100

> Note that the ULA draft, draft-ietf-ipv6-unique-local-addr-09.txt is

Exactly - two issues here - one is removing some 'loose' language from
the ULA draft, the other is a 3484 update to consider ULAs in place of
site locals.

The former could be an 'editorial' change, if meaning is preserved?

-- 
Tim/::1

---

From: Tim Chown <[email-masked]>
Date: Thu, 23 Jun 2005 17:01:26 +0100

> deployed in parallel with globals.

There is the intermittently connected network, that uses ULAs internally,
but will also use globals when connected externally and multi-addressed,
but then drop back to ULA-only when its uplink disappears again.

An example might be a community wireless network, where ADSL uplinks may be
advertised and removed over time.

-- 
Tim/::1

---

From: Mark Smith <[email-masked]>
Date: Fri, 24 Jun 2005 09:41:20 +0930

On Thu, 23 Jun 2005 17:01:26 +0100

> advertised and removed over time.

I agree, "deployed" was probably the wrong word to use. 

Regards,
Mark.

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 26 Jun 2005 00:39:52 +0200

> be added. This would be a trivial change.

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

> addresses. But wording indicates that they are not really global

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

> 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