Subject: Default site-local behavior for routers

From: Brian Haberman <[email-masked]>
Date: Wed, 30 Oct 2002 13:45:53 -0500

So, one of the items that Margaret suggested was some text in
the node requirements doc or the scoped addr arch that states
that nodes default to being in one site.

However, there has been some mention that people would prefer
different behavior in routers.  That is, the stated desire
was that, by default, each interface on a router be in its own
site.

This suggestion leads to the model where hosts with multiple
interfaces will assume that all its interfaces are in the
same site (e.g. have the same site-local zone id) unless
explicitly configured to have multiple sites.  While routers
will default to having a unique site-local zone id for each
interface (thus rendering SLs to link-local behavior) unless
explicitly configured to have multiple interfaces in the
same site.

This difference in behavior for hosts and routers leads to
some interesting issues.  One big one is how the site-local
zone ids are setup and potentially changed when a host
becomes a router or vice versa.

What are others' opinions on this issue?

Brian

--------------------------------------------------------------------
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: Roy Brabson <[email-masked]>
Date: Wed, 30 Oct 2002 15:16:02 -0500

> What are others' opinions on this issue?

The correct default really depends on the intended use of the node. Having 
interfaces default to being in different site-local scope zones makes 
sense for specialized boxes whose purpose is to be a site boundary router, 
like a home gateway router which has a WAN interface and one or more LAN 
interfaces.  For these types of specialized nodes, it probably makes sense 
to default the WAN interface to one site-local scope zone and the LAN 
interface(s) to a separate site-local scope zone.

The same type of logic could be applied to nodes which act as firewalls, 
where the "public" interfaces are in one site-local scope zone and the 
"private" intranet interfaces are in a different site-local scope zone. In 
this case, other configuration information can be used to derive the 
default site-local scope zones for the firewall's interfaces.

For a typical host or router, though, a better default would be to have 
all interfaces in the same site-local scope zone.  This is more consistent 
with what is shipping today.  Indeed, many of the routers which ship today 
are not capable of being configured as a site boundary router, much less 
default to that behavior.  Keep in mind that vast majority of hosts also 
support IP forwarding (although it may not be enabled by default), so this 
effectively says these hosts must be capable of being multi-sited.  And I 
don't think we have a good enough grasp on what the impacts are to support 
multi-sited hosts.

Not to mention the problem Brian raises above on having different defaults 
based on whether a node is a host or a router - the site-local scope zone 
IDs will change as IP forwarding is enabled or disabled.  Since the scope 
zone ID is part of the sockaddr structure and is needed to identify the 
remote partner when using non-global addresses, this could (and very well 
may) result in loss of connectivity for active connections.

Assuming that the use of site-local addresses is not restricted to sites 
which are not connected to the global internet or other sites (which is my 
preference), what I'd like to see is this (or another) WG define exactly 
what support is needed to make this work.  This includes standards to 
define what a site boundary router needs to implement, including updates 
to routing protocols and the forwarding logic as defined in the scoped 
addressing architecture.  It should also include a BCP which defines 
application impacts associated with using site-local addresses in these 
environments and gives guidance on how to work around the problems.  For 
hosts, we should indicate that the current standards only specify how a 
single-sited host should behave, and multi-sited host support is undefined 
pending possible future standards work.  But lets stop trying to define 
the default site-local scope zone configuration for hosts and routers.  If 
a router can act as a site boundary router, the router vendor can decide 
the appropriate default configuration for their product, and whether 
certain interfaces should be in the same site-local scope zone or in 
different site-local scope zones by default.

Roy

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 30 Oct 2002 13:14:35 -0800

The whole discussion about lack of definition of site boundary is bogus,
and causing a large waste of energy. We don't tell people how to bound
areas in OSPF, yet we are expected to spell out the universal definition
of a site. To a first order, the concepts are exactly the same, how much
information is exposed across administrative borders. 

An organization should probably start with the assumption that a site
boundary is exactly congruent with an OSPF area, but they may choose to
restrict it further, or expand it when it makes sense for their network.
In any case, the site boundary should never be larger than the IGP
scope, so if we are going to talk about defaults, rather than assuming
every interface is in a different site, why not assume every EGP/IGP
boundary identifies a different site? If we can get past that, maybe we
can start talking about area boundaries as a reasonable default.

Tony

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Brian Haberman
> Sent: Wednesday, October 30, 2002 10:46 AM
> To: [email-masked]
> Subject: Default site-local behavior for routers
> 
> 
> was that, by default, each interface on a router be in its own site.
> 
> explicitly configured to have multiple interfaces in the same site.
>

---

From: Keith Moore <[email-masked]>
Date: Wed, 30 Oct 2002 16:08:08 -0500

> What are others' opinions on this issue?

I'm actually thinking that the most desirable default behavior 
for routers is one that discourages use of SLs unless they're
explicitly configured.  So I am inclined to believe that a
router (or a multi-interface host when acting as a router) should 
by default treat every interface as if it were in a separate site,
and therefore refuse to forward SLs at all.

to enable SLs at a router the admin should have to label 
*each* separate interface with a site-id.   

similarly, hosts should not configure SLs by default.

that way, in the absence of any configuration, SLs simply don't
work at all.  apps on correctly-configured hosts aren't exposed 
to them because they aren't configured on any of their interfaces.
if any host does try to send packets to them, or source packets
from them, they don't get past the first router.

this also seems to produce the "right" behavior for people who
believe that SLs provide some security - default policy is to deny
all SL traffic, then you can explicitly decide when to permit it. 

I also think it produces the most desirable end-state should we 
reach consensus to deprecate/discourage SLs - if routers 
discourage SL by default then they'll continue to do the right
thing by default when it's generally realized that they were a
bad idea anyway, and they'll continue to be backward compatible
for those who invested in them.

Keith

p.s. actually I believe that routers should refuse to forward
SLs if they know of any route to any routable prefix, in order
to enforce the restriction that SLs should not be used except
on isolated networks.  so the above could be considered a 
fallback position.
--------------------------------------------------------------------
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: Wed, 30 Oct 2002 16:25:15 -0500

>can start talking about area boundaries as a reasonable default.

Actually, there has been some discussion amongst various routing-related
folks that has led to the belief that a site must always be congruent
with a single OSPF or IS-IS area.  This is necessary in order to meet the
"convexity" requirement for sites with respect to both site-local and
global addressing.

I've had an action item for a while to summarize the thread that led
to this conclusion to the IPv6 list, but I haven't gotten to it yet.
I'll do so soon.

Margaret

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 30 Oct 2002 14:27:26 -0800

Margaret Wasserman wrote:
> ...
> I've had an action item for a while to summarize the thread 
> that led to this conclusion to the IPv6 list, but I haven't 
> gotten to it yet. I'll do so soon.

I appreciate that work loads make a summary effort challenging, but in
this particular case it would seem the lower effort path would be to cut
off the IPv6 thread by forwarding the analysis. Hopefully it will make
it clear to all that the scope of SL can't exceed the scope of the IGP,
and shouldn't exceed the configured sub-scopes of that IGP without
explicit configuration.

Tony

---

From: Ole Troan <[email-masked]>
Date: Wed, 30 Oct 2002 23:07:43 +0000

> What are others' opinions on this issue?

I think default behaviour should be that a router treats site-locals
just as global addresses, i.e all interfaces in the same site.

- site borders need to be configured.
- a router connected to multiple sites needs to be configured.

we should not require all router implementations to support
"multi-site" behaviour.

/ot

---

From: Rob Austein <[email-masked]>
Date: Wed, 30 Oct 2002 20:25:31 -0500

What Ole said.

---

From: Brian Haberman <[email-masked]>
Date: Wed, 30 Oct 2002 21:24:32 -0500

For the record, my opinion follows Ole's comments.

Brian

---

From: Brian Haberman <[email-masked]>
Date: Wed, 30 Oct 2002 21:36:10 -0500

Tony,
      That is a reasonable approach and one that I could live
with.  It allows SLs to exist and control is based on tools
that are in wide use today.

Brian

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 30 Oct 2002 21:51:35 -0500

>>can start talking about area boundaries as a reasonable default.

This works pretty well to bound the problem for routing protocols
and routers.

I'm not sure that it does much, though, to address the issues that
site-locals raise for transport protocols, applications, DNS and
management protocols.  Am I missing something?

Margaret

---

From: Mark Smith <[email-masked]>
Date: 31 Oct 2002 14:07:35 +1100

Would "provider independent local addressing" be a better name for site
local addressing if Tony's model is the most commonly followed ?

I would find that a more descriptive name, as it doesn't suggest that I
have to artificially place a boundary on the addressing due to physical
geography.

Mark.

---

From: Keith Moore <[email-masked]>
Date: Wed, 30 Oct 2002 23:04:03 -0500

> local addressing if Tony's model is the most commonly followed ?

you don't want PI addresses to be constrained to be "local".  you want
to be able to privately route them between sites.

Keith

---

From: Mark Smith <[email-masked]>
Date: 31 Oct 2002 15:16:15 +1100

Oops, sorry, I think I overloaded an already defined term.

Maybe "enterprise local addressing" or something similar that doesn't
imply a geographical size or location, and indicates the addressing
uniqueness is only local to the organisation using it.

---

From: Keith Moore <[email-masked]>
Date: Wed, 30 Oct 2002 23:36:22 -0500

> uniqueness is only local to the organisation using it.

there's no need for such addresses.

Keith

---

From: Mark Smith <[email-masked]>
Date: 31 Oct 2002 16:11:01 +1100

I think there is in Australia ... 

Have a read of my previous emails.

If I was to build a very simple enterprise network between 8 capital
cities, with an single ethernet segment in each, and 7 wan links
connecting them, if I follow the current site-local definition
(geographical boundaries define site local boundaries), I think I'm
going to need 8 multi-site routers, and will have a total of 15
different site-local addressing instances.

Hmm, I think I'll just ignore the current site-local geographical
definition, and number all my links out of the 2^56 bit subnet address
space I have in a single site-local fec0::/10 address space. 

If nothing else, I don't want to pay the extra premium to a router
vendor to get a multi-site feature set on all the routers in this
network, just to follow a addressing name definition.

On the other hand, that additional feature set cost is likely to be
cheaper than the cost in explaining why every link in the network is
called a "site" to my boss. It could cost me my job.

---

From: Keith Moore <[email-masked]>
Date: Thu, 31 Oct 2002 00:29:24 -0500

if multi-site routers really did cost more than single-site routers, 
that's even more reason to not use SLs - since the same effect could 
be achieved at less cost using globals and prefix-based filtering.

however I'd be really surprised if SL filtering added to the
cost of a router.

Keith

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 30 Oct 2002 22:23:31 -0800

> there's no need for such addresses.

Enough managers of real networks created them, and still demand them
that despite your claim that there is no need, there is a requirement
that we provide something.

Tony

---

From: Mark Smith <[email-masked]>
Date: 31 Oct 2002 17:48:32 +1100

> however I'd be really surprised if SL filtering added to the

You're probably right.

On the other hand, as per Ole Troan's earlier email (which I agree
with), I don't think all router implementations should be required to
support multi-sites. 

As soon as a feature is optional, it can be charged more for, and in my
example, following the site-local philosophy, I would have to pay for
it.

BTW, I'm not sure if you miss-phrased, but we are talking about full
multi-site forwarding support (ie zones etc), not just SL filtering.

Mark.

---

From: Keith Moore <[email-masked]>
Date: Thu, 31 Oct 2002 08:12:23 -0500

> that we provide something.

that's like saying that we have to do _something_ about bin Laden,
so we might as well bomb a few thousand people who have nothing 
to do with him.  yes, that kind of logic is commonly used.  that 
doesn't make it right.

Keith

---

From: Brian Haberman <[email-masked]>
Date: Thu, 31 Oct 2002 08:21:28 -0500

> with), I don't think all router implementations should be required to

I think Ole's comments apply to specialized routers.  If you are
marketing a general purpose router, you almost have to put in
support since you don't know how or where they will be deployed.

> example, following the site-local philosophy, I would have to pay for

That depends based on my comment above.

> multi-site forwarding support (ie zones etc), not just SL filtering.

I break the problem down into two parts, pieces that already exist
and pieces that really don't.

Some of the forwarding rules for site-locals look alot like the
ingress filtering that is done today to address spoofing.  So,
the machinery exists for that.  As Ole pointed out in another
message, there is some checking that is done for LL that can be
re-used for SLs.  The difference though is that the LL check
doesn't require retrieving an index in order to check.

What doesn't really exist is the filtering of prefixes being put
into route exchange messages based on an arbitrary index (zone
id).

The other big issue is how the routing table(s) are built and
managed.  That can be a big hit on memory/storage space.

Brian

---

From: Mark Smith <[email-masked]>
Date: 01 Nov 2002 01:14:59 +1100

Does this make me a terrorist network administrator, for trying to help 
by showing how I might try to use one of the features of IPv6 in the
real world ?

Please do not bring up terrorism on this mailing list, not only is it
in-appropriate, it is in particularly bad taste after the recent
bombings in Bali.

I'm hoping you haven't forgotten the sad events that occurred in your
country just over twelve months ago. We here in Australia certainly
haven't.

As Vint Cerf wrote in a RFC recently, The Internet is for Everyone. Once
everyone has it (I'd say one of the fundamental inherent goals of IPv6),
hopefully the world can become a more tolerant place through
communication, allowing better understanding of different peoples view
points and beliefs. Hopefully the world will become small enough that
there will eventually be no "us and them".

Your views seem to me to be similar to those that cause terrorism in the
first place.

If they aren't, then using terrorism and the reactions to terrorism as
an example of why a feature should or shouldn't be implemented in IETF
developed protocols is offensive, insensitive, and irrelevant.

---

From: Keith Moore <[email-masked]>
Date: Thu, 31 Oct 2002 09:32:57 -0500

> by showing how I might try to use one of the features of IPv6 in the

No, of course not.  It's just that recent events have provided such glaring 
examples of the utter stupidity of arguments of the form
"we must do _something_, even though it won't help, and will probably do harm"
that these examples immediately come to my mind whenever I see the phenomenon
happening.  To me these examples are so obvious that I have a hard time thinking 
of other examples of this phenomenon to cite.  Such arguments are quite common.
Thankfully most of the real-world examples of this kind of reasoning do 
not result in thousands of deaths.

Let me attempt a different illustration, this time using an ancient folk tale
that may be familiar to some, and which doesn't involve any violence
(and which like any good folk tale, is told differently each time):

A visitor to Nasrudin's home finds him diligently searching his yard.

"What are you looking for?" he said.
"My car keys."
"Where were you when you last had them?"
"Inside my house."
"Why aren't you looking for them there?"
"Well, the light is better out here.  And I had to do _something_ to find them."

Keith

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 31 Oct 2002 09:59:11 -0500

>there will eventually be no "us and them".

And, hopefully, that's while we're all here -- trying to build
an Internet that can deliver on this vision.

Mark, thanks for reminding us that we're all really on the same
side.

Margaret

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 31 Oct 2002 09:51:17 -0500

>support since you don't know how or where they will be deployed.

Not necessarily.  Even if we go to the trouble of fully defining
how site-local address will work, it is still possible that the
market will decide not to support them.  If no one builds SBRs,
no one will have effective site borders.

Are there any commercial routers today that include SBR support?

Who has an implementation of an SBR that includes routing protocols?
Brian, I know you wrote one with RIPng.  Are there others?  I'd
be very interested in hearing about implementation experiences.

Does anyone have a SIP or SCTP implementation that will work in a
multi-sited environment?  Or other complex applications that pass
addressing information?  What were your experiences?

Does anyone have an operational network that uses site-local
addresses to provide private addressing within a globally connected
network?  Why did you choose to do this?  What were your experiences?
Please note that I am interested in deployed, operational networks,
not theoretical deployments.

Have any network administrators installed a two-faced DNS that
returns IPv6 site-local addresses within the site, but not externally?
How did that work out?

>managed.  That can be a big hit on memory/storage space.

Brian, could you elaborate on these things?

Thanks,
Margaret

---

From: Brian Haberman <[email-masked]>
Date: Thu, 31 Oct 2002 10:41:02 -0500

> Brian, could you elaborate on these things?

Sure.  One of the issues that I had to deal with in the scoped
addr arch was how to represent the concept that multiple RIBs
are needed to support site-locals.  The conceptual model is that
you have a RIB for globals and RIB for each unique site-local
zone id in the box.

These tables can be implemented in several ways.  One way would
be to add a zone id entry to a monolithic RIB.  This means that
uniqueness is based on (prefix,zone id) rather than just on
prefix.  Another way would be to have separate RIBs (perhaps as
an array).  Then the lookup entails finding the table that
matches the incoming zone id and then the prefix in that table.

So, right there we have a more complex indexing structure, but
it is not too bad.  It looks similar to how some products do
VPN support.

Another hit is taken in each routing protocol.  When the protocol
builds its advertisement packet, it must do this selectively.
The zone id of the outgoing interface is retrieved and the routing
protocol then builds its advertisement using the global RIB and
the site-local RIB corresponding to the zone id.  This process has
to be done for each interface.

Does anyone want to hear the gory details on the forwarding plane
or is the explanation in the scoped addr arch enough?

Brian

---

From: Brian Haberman <[email-masked]>
Date: Thu, 31 Oct 2002 10:47:06 -0500

> no one will have effective site borders.

I agree that could be a big issue.  We can't make vendors put
stuff in their boxes and we can't mandate how operators deploy
technology.  So do we only give them enough rope to make a
noose or do we give them enough to use constructively?

> Are there any commercial routers today that include SBR support?

None that I know of.

> be very interested in hearing about implementation experiences.

I started to do one for OSPF, but ran out of time.

Brian

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 31 Oct 2002 09:05:30 -0800

> Are there any commercial routers today that include SBR support?

By definition, every IGP/EGP transition is at least one example of site
border, so the answer to your question is yes.

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 31 Oct 2002 09:33:04 -0800

Brian is right, the approaches for dealing with independent routing
multiple scopes are fairly straight forward. At the same time I suspect
that the majority of sites that will use SL, will simply treat them as a
set of prefixes to be passed around in their IGP. Since it will require
both parties to misconfigure BGP to get those prefixes leaked between
enterprises, they will feel more secure about using them (note: I did
not say they would have better security, just that they would 'feel more
secure'). For this simple reason we need to meet the network manager at
his comfort zone and provide a fimilar tool. 

Yes that appears to create a problem for multi-party apps, but the
problem of disconnectedness exists without a defined SL. Since SL makes
it clear that there are places where the network will be disconnected,
there should be a note to application developers stating what the
pitfalls are, along with any known work arounds. Having a clearly
defined prefix should make that task easier.

Tony

> Sent: Thursday, October 31, 2002 7:41 AM
> Subject: Re: Default site-local behavior for routers
> 
> 
> >> What doesn't really exist is the filtering of prefixes 
> being put into 
> >> route exchange messages based on an arbitrary index (zone id).
> >>
> Sure.  One of the issues that I had to deal with in the 
> scoped addr arch was how to represent the concept that 
> multiple RIBs are needed to support site-locals.  The 
> conceptual model is that you have a RIB for globals and RIB 
> for each unique site-local zone id in the box.
> 
> These tables can be implemented in several ways.  One way 
> would be to add a zone id entry to a monolithic RIB.  This 
> means that uniqueness is based on (prefix,zone id) rather 
> than just on prefix.  Another way would be to have separate 
> RIBs (perhaps as an array).  Then the lookup entails finding 
> the table that matches the incoming zone id and then the 
> prefix in that table.
> 
> So, right there we have a more complex indexing structure, 
> but it is not too bad.  It looks similar to how some products 
> do VPN support.
> 
> Another hit is taken in each routing protocol.  When the 
> protocol builds its advertisement packet, it must do this 
> selectively. The zone id of the outgoing interface is 
> retrieved and the routing protocol then builds its 
> advertisement using the global RIB and the site-local RIB 
> corresponding to the zone id.  This process has to be done 
> for each interface.
> 
> Does anyone want to hear the gory details on the forwarding 
> plane or is the explanation in the scoped addr arch enough?
> 
> Brian
>

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 31 Oct 2002 09:33:04 -0800

Tony

---

From: Keith Moore <[email-masked]>
Date: Thu, 31 Oct 2002 13:50:20 -0500

> defined prefix should make that task easier.

having a clearly-defined prefix *does* make the need more apparent.
but having the addresses be ambiguous makes the job of dealing with 
them considerably more difficult.  

Keith

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 31 Oct 2002 15:38:39 -0500

Not true.  There is no expectation that the _same_ IP address
will point to two _different_ systems because it occurs on
different sides of an IGP/EGP transition.

Margaret