Subject: Re: C000

From: David Terrell <[email-masked]>
Date: Thu, 15 May 2003 12:28:56 -0500

On Thu, Apr 10, 2003 at 03:31:13PM +0200, Brian E Carpenter wrote:
> Let's be constructive and ignore distractions like appeals.
> Let's also assume that item (4) ["requirements for a local 
> addressing mechanism"] in the chairs' work list is relatively
> straightfoward and obvious.
> 
> Assume that we consider stable, probably unique,
> unrouteable prefixes important enough to get their own 3-bit
> prefix, and for the sake of argument let's pick C000::/3.
> 
> Further assume that we want to generate /48s.
> 
> Then the problem to solve is generating probably unique 45 bit
> numbers easily and essentially free of charge. That's clearly possible 
> in several ways, so let's not debate details.
> 
> Therefore, assume we have a way of generating such prefixes under C000::/3.
> 
> What are they going to do to the scoped architecture? Will applications
> need to treat them any differently from 2000::/3?

Problem case:
SIP A ---- SIP HUB ---- SIP B

SIP A connects to SIP HUB in the site.  SIP B is an external device not 
within the site.

A connects to HUB over a C000::/3 address pair.  B connects to HUB
with a 2000::/3 address pair.

A now needs to talk to B.

What happens?

This is _the_ demonstrated problem case for site-local.  In the
scoped world, the application can compare the zone IDs of the two
addresses being referred to each other by checking the zone identifier
of the local connection.  In your scenario, it needs to have magic
rules about C000::/3.

How is the latter easier than the former?  Scoping gives us (as a
site administrator) an accurate way to make the site boundary clear,
through host configuration (and autoconfiguration).  Picking a
(brand new!) magic prefix and starting over gives site administrators
less information to pass to clients, and zero way to tell apart a
"local site-local" address from a "remote site-local" address.  Just
because they're unique and don't have the words "site-local" in the
specification doesn't mean they won't leak, or cause problems when
they do leak, it just means we've completely dodged answering the
question, and ensured another 5 year rev cycle before an answer
gets completed.

-- 
David Terrell           | 
Nebcorp Prime Minister  | 
[email-masked]            |  The best free things in life are free.
http://wwn.nebcorp.com/ | 
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Eliot Lear <[email-masked]>
Date: Thu, 15 May 2003 11:21:40 -0700

> A now needs to talk to B.

You never get that far.  If HUB wants to talk to A and B and they reside 
in different site-local scopes, there is no way to guarantee that the 
two spaces don't clash.

Eliot

---

From: David Terrell <[email-masked]>
Date: Thu, 15 May 2003 14:11:27 -0500

> in different site-local scopes, there is no way to guarantee that the 

HUB can at least know that A's site-local address is in a different scope 
by checking zone IDs.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 16 May 2003 12:13:26 +0200

> HUB can at least know that A's site-local address is in a different scope

I'm not quite sure what a zone ID is, and we should probably have this 
discussion in the light of draft-hinden-ipv6-global-local-addr-00.txt,
not my half-baked C000 suggestion. But yes, this is a real world
problem and no address format tweaking will make it go away.
However, if HUB concludes that A and B cannot communicate, but
in fact they can due to an ad hoc VPN between them, then we are
in trouble. This is why I don't understand how simple scoping
rules can solve the problem.

   Brian