Subject: FEC0::/10 vs. FC00::/7

From: Bob Hinden <[email-masked]>
Date: Fri, 06 Jun 2003 15:46:38 -0700

I still have a small preference preference for using FC00::/7 for the 
globally unique local addresses due to the larger global ID, instead of 
reusing the FEC0::/10 prefix.  But either would work.

I think one element in the choice comes down to deciding if we want the 
default scope of these addresses to be global.  Currently the FEC0::/10 
prefix is called out in RFC3513 for special handling and everything else 
not listed (including FC00::/7) is to be treated as global unicast.

If we want these addresses to be handled differently from global unicast 
(like giving them preference over global unicast), then using the FEC0::/10 
prefix is a good choice.  If we want them to be treated the same as other 
global unicast than using FC00::/7 would be preferable.

Note that RFC3515 does allow for other specifications to define special 
handling for other prefixes, but as Alain Durand pointed out on the list 
doing so does put some additional burden on existing implementations.

Other opinions?

Bob

--------------------------------------------------------------------
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: Margaret Wasserman <[email-masked]>
Date: Sat, 07 Jun 2003 11:02:38 -0400

>reusing the FEC0::/10 prefix.  But either would work.

The problem with using FECO::/10 for these addresses is that there
are implementations that include special semantics to handle
the ambiguity of FECO::/10 addresses, such as requiring a Zone ID
to disambiguate FECO::/10 addresses, setting up separate routing
tables for separate FECO::/10 zones, etc.

In Bob's proposal, addresses are globally unique (although
they may not be globally routed), so we don't need special
semantics to handle the ambiguity.

Margaret

---

From: Margaret Wasserman <[email-masked]>
Date: Sat, 07 Jun 2003 12:14:40 -0400

Using myself as the example...

Does anyone else find it sub-optimal that we are spending so
much time arguing about what address bits should be used for
local addressing when we have yet to gain consensus on:

         - The requirements for local addressing?
         - The best technical mechanism(s) to meet those
                 requirements?
         - Whether we need local addressing at all?

Let's figure out what we really need, and _then_ argue about
the specifics of where to put the address space.

Did anyone want to comment on Tony's requirements document
and/or propose an alternative set of requirements?

Margaret

---

From: Robert Elz <[email-masked]>
Date: Sun, 08 Jun 2003 02:38:56 +0700

Date:        Sat, 07 Jun 2003 11:02:38 -0400
    From:        Margaret Wasserman <[email-masked]>
    Message-ID:  <[email-masked]>

  | The problem with using FECO::/10 for these addresses is that there
  | are implementations that include special semantics to handle
  | the ambiguity of FECO::/10 addresses, such as requiring a Zone ID
  | to disambiguate FECO::/10 addresses, setting up separate routing
  | tables for separate FECO::/10 zones, etc.

All that is OK, there's no implementation that I know of that requires
that SL addresses exist in multiple scopes.   An implementation as you
describe it will work just fine, making use only of one scope for all
of these addresses, until perhaps some later version of the system
stops using the scope identifiers altogether.

Nothing is going to break.

  | In Bob's proposal, addresses are globally unique

Once again, no, they're not.   The difference between them and the SL
that we have had is that we are going to ignore the non-uniqueness,
rather than explicitly handle it.

kre

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 08 Jun 2003 14:05:35 +0200

>          - Whether we need local addressing at all?

I maintain that it is 100% clear that we need limited-scope
addressing, and since we will never have a precise definition
of a "site", we'd better not waste our time trying to define
"site local" precisely.

> and/or propose an alternative set of requirements?

I think we should take that draft as good enough, and discuss 
Bob's proposal as a solution to those requirements.

   Brain

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 08 Jun 2003 14:01:26 +0200

> rather than explicitly handle it.

To be more precise, we are going to define them in a way that makes
them extremely likely to be unique, and then treat them as if they
are mathematically unique. To me, that's good enough.

I don't mind too much which prefix we use. A clean separation from
FEC0 might be safer.

   Brian