Subject: My Thoughts on Site-Locals

From: Margaret Wasserman <[email-masked]>
Date: Thu, 03 Apr 2003 07:01:57 -0500

I have a few thoughts to share on site-local addressing...

Many people have written to the list lately stating that site-locals
should be retained for (at least) one of these two reasons:

	- Numbering for disconnected networks.
	- Access control.
	- Numbering for intermittently-connected networks.

I do consider these things to be very important, but I do not
consider site-local addresses to be the best architectural solution
to these problems.

Site-local addresses have properties that are not needed to address
these problems, and that cause problems for routing protocols and
upper-layer protocols, such as:

	- Ambiguity (requires zone ID to disambiguate).
	- Need to retain site "convexity".
	- Single level of nesting (you can't have a further access-
		controlled site within a site).
	- Special address selection handling required at the IP
		layer and in applications.
	- Places the knowledge of private addressing in all implementations,
		instead of keeping the knowledge of routing boundaries
		constrained to the infrastructure (routers, firewalls,
		etc.)

Using random addresses for disconnected sites was proposed as an
alternative, but that is not the only alternative.  There are, in
fact, two superior alternatives that do not require any standardization
work by the IPv6 WG (or any other IETF WG):

	- Enterprises could use part of their /48 as private
		addresses and filter at private borders.  This
		is superior to site-locals because:

		- It allows nesting of private areas.
		- The owner of local addresses can be identified.
		- Non-ambiguous -- if sent outside the local area,
			they are unreachable and won't point to
			the wrong network or node.
		- Doesn't require special handling on end-nodes
			or by applications, etc.

	- Registries could offer private address allocations to
		individual enterprises/people.  This is also
		superior for the same reasons listed above.

Access control is also useful, and a simple form of access control will
be needed in IPv6.  However, site-local addresses are a poor form of
access control for two reasons:

	- Site-local boundaries need to be at routing area
		or AS boundaries (not convenient).
	- Site-local areas cannot be nested.

So, you can't have a site-local access control boundary for your corporate
site, AND a site-local access control boundary that only allows the marketing
department to use the fancy printer.

Both Steve Bellovin and Brian Zill have proposed superior access control
mechanisms based on information being passed in router advertisements, and
I think they plan to combine their proposals into a single, maximally
beneficial, form.

The intermittently-connected site problem is often raised as a reason for
site-locals.  This is an interesting problem, and it would be very good
to solve this problem, but site-locals do not provide a complete solution.
And, recent models for site-local usages (including "moderate" and
"limited") don't provide a solution for this case at all, as they would
reverse the preference for site-local addresses over global addresses
in the address selection rules.

So, while I think that the IETF needs to figure out a way to address this
type of network, site-locals may not be the best way to do it, as they
come with substantial costs for all nodes, and don't fully solve this
problem.

Just my thoughts...

Margaret

--------------------------------------------------------------------
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: "Jim Fleming" <[email-masked]>
Date: Thu, 3 Apr 2003 06:12:56 -0600

Do you have any working code ?

Also, have you considered moving your mailing list to an IPv6 transport ?
...would there be any users ?

---

From: Richard Carlson <[email-masked]>
Date: Thu, 03 Apr 2003 10:10:47 -0600

Margaret;

I have a real hard time understanding why proponents of the depreciate SL's 
claim that SL's would require special handling by applications , while 
unique PI's don't.  If an address has limited scope, i.e., there is an 
address filter somewhere in the network that prohibits global e2e 
connectivity, then sometimes applications will fail to establish 
connections using those addresses.

What I fail to see is why the SL prefix (FEC0::/10) is any different than a 
unicast prefix (say 2001:0400/32).  I contend that it isn't the SL unicast 
prefix that breaks the e2e principle, but the address filter.  The only 
difference I can see is that the SL prefix guarantees that an address 
filter will be crossed, while the unicast prefix makes no such 
guarantee.  If we accept that these filters will exist, for all unicast 
prefixes, then apps will have problems when communicating when peers are 
separated by this filter.

So I don't accept your point below that SL's require special handling by 
apps, but unique random addresses that provide the same function don't.

What am I missing that leads you to a different conclusion?

Rich

At 07:01 AM 4/3/03 -0500, Margaret Wasserman wrote:

>[snip snip snip]
>[snip snip snip]

------------------------------------

Richard A. Carlson                              e-mail: [email-masked]
Network Research Section                        phone:  (630) 252-7289
Argonne National Laboratory                     fax:    (630) 252-4021
9700 Cass Ave. S.
Argonne,  IL 60439

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 3 Apr 2003 10:23:43 -0800

Margaret Wasserman wrote:
> ...
> Access control is also useful, and a simple form of access 
> control will be needed in IPv6.  However, site-local 
> addresses are a poor form of access control for two reasons:
> 

This is bogus nonsense. 

> So, you can't have a site-local access control boundary for 
> your corporate site, AND a site-local access control boundary 
> that only allows the marketing department to use the fancy printer.

Within the site, there is no difference between the filtering
characteristics of SL & any other prefix. If your argument is that a
site can't have multiple subnets with the same prefix, well that is self
evident.

> 
> Both Steve Bellovin and Brian Zill have proposed superior 
> access control mechanisms based on information being passed 
> in router advertisements, and I think they plan to combine 
> their proposals into a single, maximally beneficial, form.

They are not superior access control mechanisms. They result in exactly
the same architectural state where some addresses on a subnet are
private while others are global. These mechanisms could just as easily
announce an FEC0 prefix, and the resulting internal filtering would be
identical. What they loose is the ability to know that the peer networks
have implemented the same filter as a backup.

> 
> The intermittently-connected site problem is often raised as 
> a reason for site-locals.  This is an interesting problem, 
> and it would be very good to solve this problem, but 
> site-locals do not provide a complete solution.

You make statements like this without any explaination or justification.
Stable addresses that persist across multiple connect/disconnect events
to different providers are in fact one problem that the current SL
approach completely solves.

>  And, recent 
> models for site-local usages (including "moderate" and
> "limited") don't provide a solution for this case at all, as 
> they would reverse the preference for site-local addresses 
> over global addresses in the address selection rules.

That is why they were broken models to begin with.

> 
> So, while I think that the IETF needs to figure out a way to 
> address this type of network, site-locals may not be the best 
> way to do it, as they come with substantial costs for all 
> nodes, and don't fully solve this problem.

The IETF needs to address all the requirements BEFORE removing the tool
that currently solves them. Doing otherwise is an irresponsible act.

Tony

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 03 Apr 2003 14:02:58 -0500

Hi Richard,

>I have a real hard time understanding why proponents of the depreciate 
>SL's claim that SL's would require special handling by applications , 
>while unique PI's don't.  If an address has limited scope, i.e., there is 
>an address filter somewhere in the network that prohibits global e2e 

The primary differences between IPv6 unicast site-local addresses (FECO::/10),
as defined today, and PI addresses are:

         1. Site-local addresses are intentionally ambiguous.
         2. Sites may not overlap or be nested.
         3. Sites need to be convex, constraining their boundaries
                 to routing area or AS boundaries.

Most of the implementation complexity comes from #1 and, IMO, we would be
much better off with an unambiguous form of local addressing.  There are
a few proposals for MAC-address based versions or unique IPv4-address
based versions.  We could also ask registries to provide globally unique
provider-independent addresses for this purpose.  Perhaps there are other
choices.  I am not actually a proponent of the "random choice" model, BTW.

#2 and #3 are constraints caused by forcing local addressing in to the
model current defined for IPv6 scoped addressing.  The scoping rules
probably make sense for multicast addresses (that's what they were
originally invented for), but I think that they place unnecessary
constraints on local addresses.

Realistically, people will want to have overlapping and nested
definitions of "local" access -- perhaps a marketing department with
a special marketing printer, inside a company that has an internal
corporate Internet site.  You can't make this work with site-locals
(no nesting), so you would already need a different mechanism for
additional levels of access control... (filters and firewalls, I'd
most likely).  So, what do you gain from having one level of
"local" defined by site-local addresses?

>What am I missing that leads you to a different conclusion?

I think what you are missing is the impact of ambiguity.  Site-local
addresses require special handling because the same address may not
point to the correct node (and may in fact point to the wrong node)
when used outside of the originating contexts.  Firewall/filter
constrained globally unique addresses don't have this problem.  You
may not be able to reach them, but you will at least know that you
were trying to reach the right node.

Margaret

---

From: Eliot Lear <[email-masked]>
Date: Thu, 03 Apr 2003 11:31:21 -0800

>>		or AS boundaries (not convenient).

Your answer does not really deserve a response.  You're guilty of the 
very thing you accuse Margaret of.  I'm curious as to how you would draw 
the boundaries.

Eliot

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 03 Apr 2003 14:45:22 -0500

Hi Tony,

> >               or AS boundaries (not convenient).

Please stop using this rude and dismissive language.  This is a
professional setting, and it would behoove you to act professionally.

The need for site-local boundaries to be at routing area or AS
boundaries has been discussed in the routing area and on the IPv6
list.  It is required in order to maintain the "convexity" of
sites which is needed to avoid situations where interally addressed
packets will be discarded when there is an internal path available
to the destination.

In order to make this work, the all-internal path to the destination
always has to be the shortest path.

Bill Fenner, Alex Zinin, Steve Deering, Bob Hinden and I (along
with a variety of other folks) spent a long time discussing this
in various fora of the past two years, and we have not come up with
any way to ensure that the internal path will be the shortest
path (== site is "convex") without requiring that site boundaries
be on routing area or AS boundaries.

Perhaps you have found a better way?  If so, please share it with
us.  Otherwise, I will persist in believing what we established
through careful analysis and extensive discussion.

>site can't have multiple subnets with the same prefix, well that is self

My point is that there is a need for nested levels of "local"
access.  So, site-locals (which cannot be nested) will not work as
the only method of "local" filtering or access control in a network.
And, once you need to use another method, what advantage is there
to also using site-locals?

Just because you have a site-local address for a node, and you and
that node are in the same site, does NOT mean that you will be able
to reach it.  Just because you have a global address for a node,
does NOT mean that you will be able to reach it.  Since applications
will have to deal with both of these situations, what advantage is
gained by using a special site-local prefix for "local" nodes?

>have implemented the same filter as a backup.

The Bellovin proposal is superior because it allows for nested
local access control.

"Private" and "Global" shouldn't be a binary choice.  A local
access control mechanism needs to deal with multiple levels of
"private".

>approach completely solves.

Local connections will only survive disconnect/reconnect if they
actually _use_ site-local addresses.  This requires more than
site-local addressing.  It require split DNS (or a similar feature
for whatever mechanism the application uses to get the address).

There is also a conflict between how you would want things to
work, by default, to be friendly to intermittently connected
sites and how you would want things to work, by default, to
be friendly with mobile nodes.  Which do you think will be more
prevalent?

>that currently solves them. Doing otherwise is an irresponsible act.

Unfortunately, site-locals are not finished.  And, there does
not seem to be WG consensus about how to finish them.

So, by fighting for them, you are essentially fighting to leave the
IPv6 WG in the "stuck" position that we've been occupying for the
past couple of years.

Margaret

---

From: Markku Savela <[email-masked]>
Date: Thu, 3 Apr 2003 23:01:02 +0300

> the only method of "local" filtering or access control in a network.

There are several unused scope levels between site local and link
local. I guess this means we need to define some additional prefixes
similer to FEC0:: for those? Then, we could have nested "sites",
"subsites" and "subsubsites" :-)

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 3 Apr 2003 12:59:30 -0800

> very thing you accuse Margaret of.  I'm curious as to how you 

Is it really necessary to point out that aligning a site-local boundary
with an existing routing boundary (AS or Area) that the network manager
has established is *extremely* convenient? Those boundaries exists for
operational reasons of filtering routing information. SL is about a
well-known prefix for routing filters, ergo aligning SL with an area or
AS border is the natural thing to do. Claiming otherwise only serves to
distribute FUD.

Tony

---

From: Richard Carlson <[email-masked]>
Date: Thu, 03 Apr 2003 15:24:16 -0600

Hi Margaret;

Let me try an rephrase my question.  I would like to know if there is 
consensus on the architectural view that IPv6 should have addresses with 
different scopes? This architectural view means that some addresses will 
not be usable for e2e communications in the global Internet.  They will 
only be usable in specific area, zones, sites (whatever label you want to 
hang on the limited portion of the Internet where they work).  I'm 
continuing to view this discussion, and the call for consensus, in the 
architectural sense, not the specific implementation laid down by your 3 
points.  Is that your intent, or am I misinterpreting your consensus call?

Again, I fail to see how deprecating site-local addresses (specifically the 
FEC0::/10 prefix) solves the underlying problem (e2e communications failing 
with some src/dst address pairs).

Rich

---

From: Bill Manning <[email-masked]>
Date: Thu, 3 Apr 2003 13:58:04 -0800 (PST)

% Hi Margaret;
% 
% Let me try an rephrase my question.  I would like to know if there is 
% consensus on the architectural view that IPv6 should have addresses with 
% different scopes? This architectural view means that some addresses will 
% not be usable for e2e communications in the global Internet.  They will 
% only be usable in specific area, zones, sites (whatever label you want to 
% hang on the limited portion of the Internet where they work).  I'm 
% continuing to view this discussion, and the call for consensus, in the 
% architectural sense, not the specific implementation laid down by your 3 
% points.  Is that your intent, or am I misinterpreting your consensus call?
% 
% Again, I fail to see how deprecating site-local addresses (specifically the 
% FEC0::/10 prefix) solves the underlying problem (e2e communications failing 
% with some src/dst address pairs).
% 
% Rich

	I -really- REALLY should just shut up and let this die.
	Rich, where is there the presumption that e2e communications
	is restricted to the "global Internet" stated as an architectural
	lema?

	Certainly some applications were designed with e2e, always reachable,
	endpoints in mind.  Such presumptions are stressed with true 
	mobility (not the tunneled back to home agent style), untethered
	and sometimes reachable networking that is evolving around us
	e.g. MANET, dccp, HIP, mDNS, zeroconf, et.al.

	Perhaps if the architectural view was e2e, sometimes reachable,
	then the bias against SL or its ilk would be mitigated.

	What do you think?

--bill
Opinions expressed may not even be mine by the time you read them, and
certainly don't reflect those of any other entity (legal or otherwise).
--------------------------------------------------------------------
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: "Tony Hain" <[email-masked]>
Date: Thu, 3 Apr 2003 14:57:55 -0800

Margaret Wasserman wrote:
> > > Access control is also useful, and a simple form of 
> access control 
> > > will be needed in IPv6.  However, site-local addresses are a poor 
> > > form of access control for two reasons:
> > >
> Please stop using this rude and dismissive language.  This is 
> a professional setting, and it would behoove you to act 
> professionally.
> 
> The need for site-local boundaries to be at routing area or 
> AS boundaries has been discussed in the routing area and on 
> the IPv6 list.  It is required in order to maintain the 
> "convexity" of sites which is needed to avoid situations 
> where interally addressed packets will be discarded when 
> there is an internal path available to the destination.
> 
> In order to make this work, the all-internal path to the 
> destination always has to be the shortest path.
> 
> Bill Fenner, Alex Zinin, Steve Deering, Bob Hinden and I 
> (along with a variety of other folks) spent a long time 
> discussing this in various fora of the past two years, and we 
> have not come up with any way to ensure that the internal 
> path will be the shortest path (== site is "convex") without 
> requiring that site boundaries be on routing area or AS boundaries.

Then why do you insist on claiming that filtering a prefix at existing
route filtering boundaries is 'not convenient'? It is not my intent to
be rude, because I really have no idea why such bogus comments are
thrown in. They appear to just be FUD intended to sway opinion,
particularly when you turn around and make technical counter arguments
at other times (like here).

> 
> Perhaps you have found a better way?  If so, please share it 
> with us.  Otherwise, I will persist in believing what we 
> established through careful analysis and extensive discussion.
> 
> > > So, you can't have a site-local access control boundary for your 
> > > corporate site, AND a site-local access control boundary 
> that only 
> > > allows the marketing department to use the fancy printer.
> >
> >site can't have multiple subnets with the same prefix, well that is 
> >self evident.
> 
> access.  So, site-locals (which cannot be nested) will not 
> work as the only method of "local" filtering or access 
> control in a network. And, once you need to use another 
> method, what advantage is there to also using site-locals?

Your assertion about nesting is ambiguous. I can certainly have a
network with a pocket of independent SL inside it. Routing between it
and the rest of the network would not be possible without globals, but
in some situations that is exactly what is required. It is also possible
to have multiple levels of filtering within a site using the FEC0 prefix
that match area boundaries. The advantages of using it don't change; it
doesn't cost anything to get, internal communications are isolated from
external prefix changes, and if a configuration error occurs at the
border the world will be configured to ignore the prefix so the network
exposure profile is lower.

> 
> Just because you have a site-local address for a node, and 
> you and that node are in the same site, does NOT mean that 
> you will be able to reach it.  Just because you have a global 
> address for a node, does NOT mean that you will be able to 
> reach it.  Since applications will have to deal with both of 
> these situations, what advantage is gained by using a special 
> site-local prefix for "local" nodes?

Applications aren't supposed to work when there are filters in place.
Network managers have a requirement to isolate some nodes from parts of
the network, so they will filter. A well-known prefix allows everyone to
block the same space so errors are not as dramatic. An additional value
of a special prefix that keeps being ignored is the ability to have
appliance devices configured to use it by default. This drastically
reduces the manual configuration required for large networks.

> 
> > > Both Steve Bellovin and Brian Zill have proposed superior access 
> > > control mechanisms based on information being passed in router 
> > > advertisements, and I think they plan to combine their proposals 
> > > into a single, maximally beneficial, form.
> >
> >identical. What they loose is the ability to know that the peer 
> >networks have implemented the same filter as a backup.
> 
> The Bellovin proposal is superior because it allows for 
> nested local access control.
> 
> access control mechanism needs to deal with multiple levels 
> of "private".

FEC0::/10 provides 54 bits for local structure. Since 'private' space is
simply filtering of routing information, there is ample opportunity for
multiple levels of private space. 

I am glad you agree that Private & Global shouldn't be a binary choice,
so we can drop all discussion of the 'exclusive' option.

> 
> > > The intermittently-connected site problem is often raised as a 
> > > reason for site-locals.  This is an interesting problem, and it 
> > > would be very good to solve this problem, but site-locals do not 
> > > provide a complete solution.
> >
> >You make statements like this without any explaination or 
> >justification. Stable addresses that persist across multiple 
> >connect/disconnect events to different providers are in fact one 
> >problem that the current SL approach completely solves.
> 
> Local connections will only survive disconnect/reconnect if 
> they actually _use_ site-local addresses.  This requires more 
> than site-local addressing.  It require split DNS (or a 
> similar feature for whatever mechanism the application uses 
> to get the address).

If topology information is exported outside its scope of relevance, the
process responsible for doing that is broken. This is true even when the
topology information is not ambiguous. For truly local connections,
split DNS is not required. Where that becomes a requirement is for
applications that leave the local context. Even there, the application
*could* be intelligent enough to recognize when the /48 doesn't match
and ignore any SL that it might have gotten back. 

> be friendly with mobile nodes.  Which do you think will be 
> more prevalent?

A mobile node knows that it is mobile, while other devices in a site
won't have a clue about the connection state at the border. If you want
to count devices, it is currently heavily weighted toward intermittent,
and upcoming the stationary appliance market will easily exceed the
mobile node market because people have many more appliances in the home
or office than mobile devices they are willing to carry. In any case,
there is no reason not to set the general default to SL, with mobile
nodes having the opposite. When a MN knows it is not home (which it has
to know to contact its HA), it should simply ignore any SL.

> 
> > > So, while I think that the IETF needs to figure out a way 
> to address 
> > > this type of network, site-locals may not be the best way 
> to do it, 
> > > as they come with substantial costs for all nodes, and 
> don't fully 
> > > solve this problem.
> >
> So, by fighting for them, you are essentially fighting to 
> leave the IPv6 WG in the "stuck" position that we've been 
> occupying for the past couple of years.

No, I have been stating that we need to solve the perceived problems in
better ways FIRST. People will choose the path of least resistance. If
we provide them a better tool that actually meets their requirements,
they will move of their own accord. If we try to remove the tool because
we are afraid, and offer only a vague promise that we might get around
to it if we ever agree that their requirements are worth our valuable
time (re: MW- I do not believe that we want to impose a costly and
complex solution on _all_ IPv6 nodes so that a few of them can work
properly in this unusual situation.), they will consider the IETF
irrelevant and will make their networks work. Whatever that takes. 

I don't want the WG stuck, and have been working on an addressing plan
that would in fact help with the address uniqueness case. I have not
brought it to the WG because it was initially targeted at the
multi-homing issue. If you would like me to submit it as a WG draft for
consideration as a mechanism for unique values that don't require a
registry, I am willing to do that. If it were coupled with the
Bellovin/Zill RA, many of the requirements would be dealt with. That
does not mean all are solved, so we still have work to do before
deprecating SL. If we do it right, once we address all the requirements,
nobody will even care about SL. At this point we don't even know if we
can address all the reqirements with other mechanisms, so if we continue
down the current path of doing it wrong, chaos will reign. 

Tony 

PS: I forwarded my SL requirements draft to the ID editor earlier today
as a personal draft. If there is interest in that becoming a WG
document, I will change the name and resubmit it.

---

From: Richard Carlson <[email-masked]>
Date: Thu, 03 Apr 2003 17:28:13 -0600

Hi Bill;

I'm not sure I can answer your question, so I'll simply state my personal 
option.

I reread the IPv6 address architecture draft before my last reply and it 
clearly states that not all e2e connections will succeed.  That is, some 
addresses only work within a limited scope (link-local, site-local, and 
global).  I believe this limited scope view matches the reality, were 
network managers and institutions block certain connections.  I also 
believe this is a correct architectural position to take.  Finally I agree 
that if this were the commonly accepted view, then discussions on how to 
achieve this goal would take place.

Rich

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 03 Apr 2003 16:48:22 -0800

Hello Richard,

Reading your note, I thought of something that might be useful
in the discussion.

Richard Carlson wrote:

>                                                         That is, some
> believe this is a correct architectural position to take.

In this excerpt, I suggest replacing the concept of addresse "working"
by "are routable".  This does make sense, and moreover it allows a
possibly important refinement on the meaning of "addressability".

I would like to suggest that a host is "addressable" at a certain
address if a packet, with that particular destination address, would
be accepted by the host.

A host is "routable" at the address if routers know how to route
packets to some link where the host is able to receive it.

I hope the distinction is clear.  For instance, I am typically
addressable as Charles E. Perkins, but some messages addressed
with that as a destination address cannot be delivered to me,
depending on the transmission medium and location of the source
and so on.   Maybe the distinction has already been made, but
I don't remember seeing it lately.

If you like that distinction, then I think it means that site-local
addressability as a concept should be replaced by site-local
routability.  That puts it squarely in the domain of routing
configuration (and protocol), and takes it even farther away
from proper visibility by applications.

Anyway, I prefer globally unique but not-necessarily-routable
addresses to replace site-local addresses.  I don't see why
they shouldn't have prefix FEC0:/10, and I don't see why whatever
document deprecates site-locals should not also reserve that
prefix for the provider-independent uses that have been proposed.
The allocation mechanism could be discussed further, but
the addresses would be taken on the understanding that they
would not be globally routable.  If a particular recipient wishes
to make private routing arrangements, then that's their business.

Regards,
Charlie P.

---

From: Alex Zinin <[email-masked]>
Date: Thu, 3 Apr 2003 23:46:50 -0800

Tony,

> AS border is the natural thing to do. Claiming otherwise only serves to

Hmmm... I'm afraid you may be misunderstanding the reason for areas
and AS'es. They exist to ensure scalability of the routing protocols
by reducing the number of direct neighbors and network nodes within
the visible part of network topology routers need to work with, amount
of state routers have to maintain and the level of activity they have
to deal with (just to mention a few, there's more to that). Filtering
of routing information is definitely not the driving factor for those
boundaries. It will be interesting for you to know that it is really
rare when route filtering is done between areas within an OSPF domain,
or between member AS'es within a BGP confed.

As far as boundary placement is concerned, adding sites to routing,
though possible, would add another dimension of complexity to network
operations--requirements driving the placement of site boundaries may
be conflicting with those driving normal area/domain boundaries, for
example.

Alex