Subject: A different FEC0::/10 proposal

From: Andrew White <[email-masked]>
Date: Fri, 04 Apr 2003 18:16:45 +1000

Let's ask a different question.  Would the following be acceptable:

-----
The address space FEC0::/10 is reserved for non-global use.  It is intended
not to be globally routeable.  All routers MUST by default blackhole any
packet destined to FEC0::/10, and MAY return a 'destination unreachable'
message.

'Sites' using FEC0::/10 addresses MUST implement a filter at the 'site
border' that discards source or destination addresses in the FEC0::/10
space.  Routing protocols MUST NOT exchange reachability information
concerning FEC0::/10 across the border.

Any router or node not explicitly configured to do otherwise MAY discard
(silently or otherwise) any packet with a source or destination address in
FEC0::/10 space.

Applications MAY choose to treat FEC0::/10 addresses differently to other
addresses, and MAY prefer or disprefer them.  Applications MAY assume that
FEC0::/10 addresses will be filtered before reaching the global internet.

-----

This seems to cover the minimum requirements of the relevant parties.  The
only global requirement is that all routers by default black-hole
FEC0::/10.  If you choose to use site local addresses, then you come under
the border router requirements given in the second paragraph.

The only bugbear I can see is source address selection.  One easy solution
is to 'prefer closest match' to whatever destination address the application
selected, which will mean SL matches SL and link-local matches link local. 
Ensuring non-SL matches non-SL may be slightly trickier, depending on
prefixes, though the current policy of allocating from 0000::/12 will prefer
global-global.

And maybe something should be added to say "If you stick these things in a
globally accessible DNS, don't be surprised when connections to your hosts
fail."  And maybe a policy to NXDOMAIN reverse lookups for
[C-F].E.F.in6.arpa.

In short, there is almost no extra effort for those who don't implement SL
addresses - all the work is pushed to those who do.

Notice that the above text says nothing about how FEC0::/10 addresses are to
be allocated.  All it does is reserve the space as 'not globally routeable'
and put policies in place to stop this information getting where it
shouldn't.

-- 
Andrew White                [email-masked]
--------------------------------------------------------------------
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: Brian E Carpenter <[email-masked]>
Date: Fri, 04 Apr 2003 15:31:45 +0200

This doesn't resolve the problem of ambiguous subnet prefixes
when routing domains merge. So it doesn't go far enough IMHO.

   Brian

---

From: Andrew White <[email-masked]>
Date: Mon, 07 Apr 2003 12:40:08 +1000

> when routing domains merge. So it doesn't go far enough IMHO.

That's because dealing with uniqueness and merging is a deployment issue,
not an architectural issue.  The proposal specifies what the routing system
and applications need to know about these restricted deployment addresses
for correct general operation.

Achieving the uniqueness criteria is actually rather easy.  HOW to do it is
up to the person deploying the site.  Workable solutions include generating
unique /64 subnet IDs ( draft-hinden-ipv6-global-site-local-00.txt,
draft-white-auto-subnet-00.txt ), generating a /48 based on the MAC of the
root router, or allocating a unique /48 from a registry.

Of course, if you're in the mood to shoot yourself in the foot, you could
number your site from fec0::/48.

I think we need to divide the problem space into two parts:

- Cleaning up site-local and scopes:
  - Enforcing the global unrouteability of the FEC0::/10 prefix.
  - Otherwise removing scope processing from address architecture.

- Document recommended ways of allocating FEC0::/10 addresses to
'near-enough' guarantee uniqueness.

The first change makes FEC0:://10 the same as any other filtered address,
with one little exception - everybody agrees that this is to be filtered.

A well-known non-globally-routeable prefix allows applications to make
decisions based on scope: "I'd rather use / not use filtered addresses".  As
a default, I'd recommend the rule "If I have an address in FEC0:://10 and
the destination offers FEC0:://10, try that first."  Assuming longest-match
destination address selection, this will work for both the situation where
FEC0:://10 exists and doesn't.  Of course, some applications will override
this and say "no, don't give me an FEC0:://10".  The convenient property is
that applications can care if they want to, and otherwise can remain
ignorant.

The second point deals with the ambiguity problem.

---

From: "Nick 'Sharkey' Moore" <[email-masked]>
Date: Mon, 7 Apr 2003 13:16:34 +1000

> Let's ask a different question.  Would the following be acceptable:

I like the direction Andrew is taking, but how about an alternative
set of rules which will cope with multiple scopes a bit better. 
The precise meaning of 'scope' has to be clarified of course,
but I imagine it can be derived from the top few bits easily enough.

* A node sending a packet MUST use an source address in the same scope
  as the destination address (except for Neighbour Discovery purposes)

* A router MUST NOT forward a packet with different source address
  and destination address scopes, and MUST NOT forward a packet
  to an address of different scope than the packets
  source/destination address scope.

* A router MUST NOT advertise a prefix or a route to a prefix on an
  interface which does not have an address with the same scope
  as that prefix.

These rules implicitly prevent site-scope packets and routes from leaking
beyond the site.  Note, for example, that since the site-edge routers
won't have SL addresses on their outside interface, they won't leak
SL traffic, and since core routers won't have GUPI addresses, they
won't transmit SL traffic anyway.
If it is necessary to connect a site across the Internet, this can be
done by VPNing / tunnelling.

-----Nick

---

From: [email-masked]
Date: Mon, 07 Apr 2003 13:53:12 +1000

> won't transmit SL traffic anyway.

	Stop making assumptions about what sites a machine belongs in.
	Multi sites machines need to be catered for.

--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]
--------------------------------------------------------------------
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: Måns Nilsson <[email-masked]>
Date: Mon, 07 Apr 2003 10:40:44 +0200

--On Monday, April 07, 2003 12:40:08 +1000 Andrew White
<[email-masked]> wrote:

> not an architectural issue.  

Might be so, but I think you are ignoring a lot of human behaviour patterns
when you believe it is a simple matter of operation to DTRT. People will
choose what they believe (and all too eager vendors insist) is the easy way
out. I strongly oppose the creation of guns with an extra barrel pointed
toward the users feet. 

> The proposal specifies what the routing
> system and applications need to know about these restricted deployment
> addresses for correct general operation.

The application must not have to know the network structure. That way lies
madness. 

-- 
Måns Nilsson            Systems Specialist
+46 70 681 7204         KTHNOC  MN1334-RIPE

We're sysadmins. To us, data is a protocol-overhead.

---

From: Bill Sommerfeld <[email-masked]>
Date: Mon, 07 Apr 2003 20:19:48 -0400

> packet destined to FEC0::/10, and MAY return a 'destination unreachable'

What's the rationale for having differing behavior in routers and
hosts?  It's becoming increasingly common for hosts to have multiple
interfaces (including servers with multiple built-in ethernet ports
and laptops with both wired and wireless connectivity).  The laptop
case seems particularly likely to "accidentally" end up on two "sites"
at the same time..

It would be more consistent for both hosts and routers to blackhole
fec0::/10 by default..

					- Bill

---

From: Andrew White <[email-masked]>
Date: Tue, 08 Apr 2003 13:08:59 +1000

Måns Nilsson wrote:
> > That's because dealing with uniqueness and merging is a deployment
> > issue, not an architectural issue.
> 
> Might be so, but I think you are ignoring a lot of human behaviour
> patterns when you believe it is a simple matter of operation to DTRT.
> People will choose what they believe (and all too eager vendors insist)
> is the easy way out. I strongly oppose the creation of guns with an
> extra barrel pointed toward the users feet.

You'll note I mentioned 4 different proposals for doing this right, several
of which are relatively trivial to deploy.  I see it as a two part process:

(1) How the network that doesn't want to consider SL addresses should treat
FEC0://10 prefixes.

(2) How sub-networks that DO want to consider SL addresses should treat
FEC0::/10 prefixes.

My comment is:

* Multiple non-unique address scopes add complexity, and don't gain much
that can't be done via prefixes.  Remove them.

* FEC0:://10 as a PI non-routeable space has significant value to many
applications.  Let's enforce the global non-routeability in the
architecture, and then we can deal with how to use it locally.

> The application must not have to know the network structure. That way
> lies madness.

Would that were true.  If everything is single-homed, then you don't need to
know about network structure simply because you can't do anything about it. 
You have one destination and one source.  The only dimension you have
control over is time.

However, once anything is multi-homed, you have options.  Some addresses may
work while some may not.  In a multi-homed environment, a robust application
will try various source-destination pairs.  Given that this is happening, it
makes sense to hint to the application that some pairs are likely to work
and some are likely to fail.

Note that any situation where a single name could resolve to more than one
address can be considered multi-homing.

---

From: Måns Nilsson <[email-masked]>
Date: Tue, 08 Apr 2003 08:10:31 +0200

--On Tuesday, April 08, 2003 13:08:59 +1000 Andrew White
<[email-masked]> wrote:

> (1) How the network that doesn't want to consider SL addresses should
> treat FEC0://10 prefixes.

As IANA "reserved" -- A bogon filter question. 

> that can't be done via prefixes.  Remove them.

I say remove all non-unique bar LL and loopback. 

> architecture, and then we can deal with how to use it locally.

It has significant issues in network operations 2 years after somebody
chose to deploy SL and the company merges with another, that happened to
take the same prefix. Have you ever tried this? I have, though in v4-land
with multiple instances of the same RFC1918 adresses. I have been there,
done that and gotten the straitjacket. I do not want even my enemies to
endure that. 
 
> Would that were true.  If everything is single-homed, then you don't need
> to know about network structure simply because you can't do anything
> about it.  You have one destination and one source.  The only dimension
> you have control over is time.
>
> However, once anything is multi-homed, you have options.  Some addresses
> may work while some may not.  In a multi-homed environment, a robust
> application will try various source-destination pairs.  Given that this
> is happening, it makes sense to hint to the application that some pairs
> are likely to work and some are likely to fail.
> 

No, that is redundancy in DNS. Worng answer. 

Multihoming means that there are several paths through the default-free
zone  via which a given prefix can be reached. These paths are logical
(AS-path) as well as physical (2 different cables into the data center
where the prefix lives.). No application I know of -- short of BGP and the
brain of the tech who runs it -- has to deal with this. It just works. This
is multihoming. Multiple prefixes and source routing are evil things that
break this "just works" stuff and therefore must go away, for they
implicate smartness in the wrong layers.

---

From: Andrew White <[email-masked]>
Date: Tue, 08 Apr 2003 17:08:57 +1000

> done that and gotten the straitjacket. I do not want even my enemies to

Are you deliberately ignoring the second part?  

> > (2) How sub-networks that DO want to consider SL addresses should treat

The assumption of all these SL proposals is that we define good mechanisms
for setting up the SL space.  Several programmatic and allocated mechanisms
have been proposed to ensure global uniqueness.

Yes, people are free to ignore them.  But then I'm ALSO free to use someone
else's global address internally.  Or drive the wrong way up one way
streets.  Or do a bunch of other stupid things deliberately ignoring the
recommendations.  And usually, it's considered my fault when things don't
work because of it.

> >> The application must not have to know the network structure. That way

[...]

> zone  via which a given prefix can be reached. ...

Ok.  We're talking different definitions of multihoming.  Replace all
mention of 'multihoming' with 'a node having more than one IP address'.

That said, you've missed my point (and Tony Hain's as well).  Throw a filter
in there.  Or perhaps multi-path multihoming with a misconfigured link.  I
(as application writer) pick a destination address (as returned by
gethostbyname or similar).  I attempt a connection.  It fails.

At this point I have two options.
(1) I give up.
(2) I try a different address offered (remember, I may have received more
than one).

At some point, the end host in a multi-homed scenario MUST make a decision
which address to choose.  And that choice may be wrong, and if so the
application needs to have a recovery mechanism.  Using a common top-level
prefix for private addresses provides a way to bias that choice.

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 08 Apr 2003 07:36:13 -0400

Hi Andrew,

>prefix for private addresses provides a way to bias that choice.

There are some choices other than modifying existing applications to know
about address scope, such as:

Returning only global addresses in the default APIs.  Applications that
know how to handle locally scoped address could ask for them explicitly.

There are also alternatives to split DNS for getting local addresses
from the DNS, such as:

A special local DNS domain (such as .local) or a different DNS record
to retrieve local addresses.

I don't think that we should limit the possible solutions in IPv6 to
the range of solutions available in IPv4 today.

Margaret

---

From: Andrew White <[email-masked]>
Date: Wed, 09 Apr 2003 16:31:03 +1000

Resend to list (sorry Margaret):

> know how to handle locally scoped address could ask for them explicitly.

I think this misses my point.  There are 2 types of addresses:

- addresses that are explicitly filtered.
- addresses that are silently filtered.

In the current v4 architecture, RFC1918 addresses are explicitly filtered. 
The documentation says that they are not global.  Other v4 addresses are not
in fact global.  They might be blocked by filters on the local site or by
filters on remote sites.  They will be blocked if they hit the outside of a
NAT (evil things that they are).

The same logic applies for v6, except we hope for fewer NATs.

Because of these considerations, any application that comes into contact
with a multi-address end node (src or dst) needs to be aware of the
functional effects of filtering - some source-destination pairs may work
while others may fail.  This is without reference to site local addresses.

How do SLs fit?

In almost every private address deployment scenario I've seen, if an SL
address (in the correct functional scope) it is at least as reliable as a
global address (except for site merges with bad SL prefixes, but I think
we're all agreed that we need to define mechanisms to ensure good NRPI/SL
prefixes).

Therefore, the application doesn't suffer from using them unless it intends
to do address forwarding.  Longest-Prefix-Match source selection will ensure
SL destinations get SL sources, and global destinations get global sources. 
If you don't have a global source, you probably aren't supposed to be able
to make an external connection.

In the address forwarding case, SLs make a big difference.  If the site uses
SLs for it's internal network, then applications have a very easy way of
knowing which prefixes are 'most likely' to be filtered, and which are not. 
If a site instead filters some 'global' prefixes, it's trial and error. 
Ultimately, it's trial and error anyway, but at least this way you get hints
which trials are most likely to succeed.

Does anyone have a compelling argument why applications that do not forward
addresses outside the site (and apps which do ought to know who they are, or
at least the person that configures them should) would find it a bad idea to
use non-routeable priavte addresses for in-site communication?

Would it be a good thing to redefine FEC0::/10 'site-locals' as a
non-routeable private addresses?  This seems to be how most people who want
them intend to use them.  Note that I am explicitly not suggesting they must
be registered, but instead make use of the various auto-allocation drafts to
ensure acceptable uniqueness.

> to retrieve local addresses.

That's certainly an option, and one we have implemented.

---

From: "Nick 'Sharkey' Moore" <[email-masked]>
Date: Thu, 10 Apr 2003 09:22:35 +1000

> know how to handle locally scoped address could ask for them explicitly.

Hmmm ... I'm not that keen on this one, since it may mess stuff up 
for nodes on sometimes-connected networks.  

> to retrieve local addresses.

Yeah, I was thinking along these lines myself ... if you enforce
scoping rules such that for a given packet S(source) MUST= S(dest)
a lot of the address selection problems go away, I think.  

-----Nick