Subject: RE: PI/metro/geo [Re: The state of IPv6 multihoming development]

From: "J. Noel Chiappa" <[email-masked]>
Date: Fri, 1 Nov 2002 11:45:13 -0500

> From: "Tony Hain" <[email-masked]>

    > operational issues in the edge enterprise space favor provider
    > independence for maximum flexibility.

No doubt operational issues in the edge enterprise space would favor
perpetual motion machines - if they existed.

	Noel

---

From: "Craig A. Huegen" <[email-masked]>
Date: Fri, 1 Nov 2002 11:03:51 -0600 (Central Standard Time)

> perpetual motion machines - if they existed.

As would operational issues in the ISP space.  Can we please quit the
bickering?

The point that Tony H. is trying to make (I think, correct me if I'm
wrong here) is that the multi-PA solution makes life very easy for ISP's
while throwing all of the operational issues of supporting such a solution
on the end-sites.

As an operator of an enterprise network with tens of thousands of
segments, I fully agree with that statement.  Many other enterprises I've
spoken to also concur with that statement, and are holding back on IPv6
deployment for that reason.

With that said, let's find some solutions.  I also agree with the idea of
separating router goop from identities; however, I also am a pragmatist
and am concerned with the existing applications that would break with
this.

/cah

---
Craig A. Huegen, Chief Network Architect      C i s c o  S y s t e m s
IT Transport, Network Technology & Design           ||        ||
Cisco Systems, Inc., 400 East Tasman Drive          ||        ||
San Jose, CA  95134, (408) 526-8104                ||||      ||||
email: [email-masked]       CCIE #2100      ..:||||||:..:||||||:..

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 1 Nov 2002 18:34:07 +0100 (CET)

> while throwing all of the operational issues of supporting such a solution

Craig, I've been looking at your messages to this list from the past
week or so to see what exactly your position on identifier/locator
solutions are, but I've been unable to distill anything definitive. So
lat me ask you if a solution with the following properties is acceptable
to you:

As far as your own hosts, the DNS and remote hosts are concerned, hosts
in your network have a single address. However, at the edges of your
network you need boxes that do some address magic so your packets get to
pass through backbone networks as if you were using regular PA. Traffic
engineering is still possible as before, or can be done with finer
granularity, at or very close to the edges but requires more effort (ie
extra hardware, or more processing on existing hardware) to do.

You have a choice between being reachable without any multihoming
benefits for people who do not implement the new scheme, but you have to
use PA addresses, or you can use PI but no interoperation with hosts
that don't implement the new multihoming solution(s) or sit behind a box
that handles this for them.

I'm not saying this is exactly what a solution will look like (hopefully
we can improve on this) but I'm pretty confident a more advanced
multi-address solution can meet the above description.

Iljitsch

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 1 Nov 2002 10:40:45 -0800

Iljitsch,
You raise a point here that I think gets lost in the mapping proposals. 
'As far as your own hosts, the DNS and remote hosts are concerned, hosts
in your network have a single address.' 
If the upper 48 bits are constant in DNS, but continually changing in
the routing system, there needs to be a way to pass the possible set of
topologically appropriate replacement values between the CPE routers.
Since this protocol would inherently have to be run between
organizations that have no trust relationship, how that be deployable?
If it were run between the PE routers, trust is managable to a point,
but what would prevent something like the POTS practice of slamming?

Tony

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Iljitsch van Beijnum
> Sent: Friday, November 01, 2002 9:34 AM
> To: Craig A. Huegen
> Cc: [email-masked]
> Subject: RE: PI/metro/geo [Re: The state of IPv6 multihoming 
> development]
> 
> 
> > wrong here) is that the multi-PA solution makes life very easy for 
> > ISP's while throwing all of the operational issues of 
> supporting such 
> > a solution on the end-sites.
> 
> Craig, I've been looking at your messages to this list from 
> the past week or so to see what exactly your position on 
> identifier/locator solutions are, but I've been unable to 
> distill anything definitive. So lat me ask you if a solution 
> with the following properties is acceptable to you:
> 
> As far as your own hosts, the DNS and remote hosts are 
> concerned, hosts in your network have a single address. 
> However, at the edges of your network you need boxes that do 
> some address magic so your packets get to pass through 
> backbone networks as if you were using regular PA. Traffic 
> engineering is still possible as before, or can be done with 
> finer granularity, at or very close to the edges but requires 
> more effort (ie extra hardware, or more processing on 
> existing hardware) to do.
> 
> You have a choice between being reachable without any 
> multihoming benefits for people who do not implement the new 
> scheme, but you have to use PA addresses, or you can use PI 
> but no interoperation with hosts that don't implement the new 
> multihoming solution(s) or sit behind a box that handles this 
> for them.
> 
> I'm not saying this is exactly what a solution will look like 
> (hopefully we can improve on this) but I'm pretty confident a 
> more advanced multi-address solution can meet the above description.
> 
> Iljitsch
> 
>

---

From: David Conrad <[email-masked]>
Date: Fri, 01 Nov 2002 11:20:08 -0800

Tony,

> but what would prevent something like the POTS practice of slamming?

Quarter-baked idea.  How about:

<n bits identifer, reversed>.route.arpa AAAA <8-n bits routing locator>

DNSSEC signed, with the globally unique identifier "owner" holding the KEY?

Multihoming could be implemented by:

<n bits identifer, reversed>.route.arpa AAAA <8-n bits routing locator>
                                        AAAA <other provider locator>
                                        AAAA <other provider locator>
                                        ...
                                        SIG  <blahblahblah>

The border router/tunnel end point does the lookup, chooses the routing
locator to prepend to the identifier.

Hmmm.  It'd be nice if the transport layer only looked at the identifier for
checksums.

Rgds,
-drc

---

From: "Aldrin Isaac" <[email-masked]>
Date: Fri, 1 Nov 2002 18:44:07 -0500

hi all,

i've been following this thread for several days, and i have some comments (part 1) as
well as an approach (part 2) towards resolving some operational issues with multi-homed
hosts.  i hope i can provide a different perspective by offering some representation from
the non-isp, non-vendor community.

part 1:

with regards to transport session continuity, a long term goal in the form of SCTP or a
similar more secure transport protocols seems neccessary.  but for now, people will
work-in application level recovery if they really need it.  that's what the smart ones do
now, especially since even current ipv4 multi-homing practices don't guarantee protection
from all failure modes.  if a developer has to write an application that is
misson-critical, s/he's definitely going to have to figure out how to make it recover if
an interface, network, system or datacenter fails.  people who provide mission critical
applications are willing to pay a price to make sure their applications recover regardless
of failure mode (either by operational procedures or automatically).

for applications that absolutely cannot accept discontinuity for established layer-7 try
this: connect using SSL transport, create and pass a temporary layer-7 session identifier
with an "in-active lifetime" (say one minute),.. and if your SSL transport session gets
disconnected, both ends maintain state for that layer-7 session for one minute,
re-establish a new SSL transport connection within one minute, send your layer-7 session
key and resume layer-7 session.  or wait for SCTP or a better-than-SCTP protocol.  or face
the fact that there are no layer-3 guarantees today so don't expect them tomorrow.  (this
is a half baked)

i believe that, if the v6 TCP stack would provide enhanced options to allow a developer to
ask the stack to "from the list of addresses for a name try an address then skip to the
next address if there is a failure to connect after 3 attempts spaced at 10 second
intervals or if a destination unreachable is received, etc and repeat till end of list" it
may make it easier on developers to deal with multiple addresses.  i.e. a configurable
auto-select and connect call.  something like this would allow those who are familiar with
how the net works to provide a foundation for others to stand on.  providing a standard
interface across platforms would be a bonus.  functionality like this available "by
default" in every system may be sufficient to satisfy those 11,000 sites that announce
their prefixes into the IPv4 DFZ such that they instead announce multiple addresses per
host to the DNS.

I'm much more concerned about the operations aspect of multi-homed hosts.  As has been
pointed out before, the current multi-homing makes the life of ISPs much easier, but it
makes the life of certain other organizations no easier.  in the end the internet may have
to carry less routes than a very large organization.  the state of the internet routing
table is critical to those who have wares to sell to the general public (like
connectivity, merchandise, nude pictures, etc), but the internet protocol is also heavily
used by those who interconnect privately as well.  i.e. operations is critical to all -
not just ISPs.

part 2:  - another quarter baked idea

in order to simplify the operations of routing multi-homed hosts, i have been thinking
about an approach that may satisfy the operations needs of some of us.  this approach is
geared for enterprises.

this approach:
(1) eliminates requiring having to support multi-interface hosts as a means of site-exit
backup
(2) eliminates the advertisement of prefixes
(3) reduces the number of routes to manage inside the site
(4) avoids having to do source-based forwarding to the appropriate site exit in order to
avoid having ISPs drop packets where the source address prefix doesn't belong to them.
(5) simplifies the life of private network providers by eliminating the requirement that
you must provide transit to the DFZ to get a global-prefix.
(6) ??
[obviously most of the above imply one another.]

it appears that this appoach will not reduce the security or resilience of connections
that we can have today.

the short version of the approach is as follows:

assume that a site:

(1) uses site-border and internal routers that are capable of intra-site routing using
only the SLA portion of the IPv6 destination address.  this obviously means a max of 2^16
subnets per site.

assume hosts in that site:

(2) have one site-local address

for outgoing connections:

(3) host performs a "forward site-exit-discovery" for site-external destinations.  the
forward site-exit-discovery response would return <1> a prefix that matches the
site-external destination address <2> AND a global-prefix (source-prefix) associated to
that site-exit + next-hop ISP <3> AND a reachable anycast or unicast site-local address of
that site-exit (site-border) router.

NOTE: the site-exit router could also be configured to <1> return a "::/0"
destination-prefix along with the global-prefix and site-exit address, i.e. a "default
route" associated to the global-prefix <2> or if the router is running an EGP, the
destination-prefix could be the longest match prefix for the destination address <3> or if
multiple site-exit routers peer using IBGP, than the site-exit router can additionally
return the site-exit address and the global-prefix of the best site-exit (this may require
some new MBGP knobs).

(4) the host would insert this source-prefix, destination-prefix and site-exit address in
a special "site-external" routing table.  these route entries are special route entries
used to allow the host to select the appropriate global source-prefix to communicate with
a site-external address and to source-route via the appropriate site-exit.  site-exit
discovery would be repeated if any destination associated to that
source-destination-prefix pair becomes unreachable.

(5) for the initial packet sent to a site-external destination, use the source-prefix
associated to  the best matching site-external destination route entry.  packets sent to
the site-external destination would include a routing header where the associated
site-exit address would be the first destination of the packets.  all connections that are
"in-progress" would be routed based on site-external route entries that match both source
and destination prefixes, i.e. only the initial localhost-originated packet can route
purely by best matching destination-prefix.  the host could probably create a temporary
pseudo-interface with that source-prefix for the duration of all connections that use it.

for incoming connections:

(6) accept any prefix so long as the SLA and interface portion belong to the host.  the
host could also create a temporary psuedo-interface to handle the connection.

(7) perform a "reverse site-exit-discovery" against the incoming global-prefix (i.e.
destination address field of incoming packet) to discover what the ingress site-exit of
the incoming packet was.  the site-exit-router would return the same results as in (4) but
without any IBGP optimizations.

(8) traffic sent to site-external address would work as in (5)

additionally:

(9) the site-exit-discovery and "site-external" routing table approach can be used for
both temporary global "pseudo-interfaces" described above as well as standard global
interfaces that are configured today using router-advertisements.

this approach OBVIOUSLY implies that the site-border (site-exit) routers are TRUSTED and
only attract traffic with global-prefixes that have been assigned to the site.  most
enterprises fit this mold.

i'm sure this approach is chock-full-of-holes since it's a half-baked idea.  but i figure
it may give a fresh perspective to some of the problems.

-- aldrin

p.s. sorry about the run-on sentences.

% -----Original Message-----
% From: [email-masked] [mailto:[email-masked]]On
% Behalf Of Craig A. Huegen
% Sent: Friday, November 01, 2002 12:04 PM
% To: J. Noel Chiappa
% Cc: [email-masked]
% Subject: RE: PI/metro/geo [Re: The state of IPv6 multihoming
% development]
%
%
% On Fri, 1 Nov 2002, J. Noel Chiappa wrote:
%
% >     > operational issues in the edge enterprise space favor provider
% >     > independence for maximum flexibility.
% >
% > No doubt operational issues in the edge enterprise space would favor
% > perpetual motion machines - if they existed.
%
% As would operational issues in the ISP space.  Can we please quit the
% bickering?
%
% The point that Tony H. is trying to make (I think, correct me if I'm
% wrong here) is that the multi-PA solution makes life very easy for ISP's
% while throwing all of the operational issues of supporting such a solution
% on the end-sites.
%
% As an operator of an enterprise network with tens of thousands of
% segments, I fully agree with that statement.  Many other enterprises I've
% spoken to also concur with that statement, and are holding back on IPv6
% deployment for that reason.
%
% With that said, let's find some solutions.  I also agree with the idea of
% separating router goop from identities; however, I also am a pragmatist
% and am concerned with the existing applications that would break with
% this.
%
% /cah
%
% ---
% Craig A. Huegen, Chief Network Architect      C i s c o  S y s t e m s
% IT Transport, Network Technology & Design           ||        ||
% Cisco Systems, Inc., 400 East Tasman Drive          ||        ||
% San Jose, CA  95134, (408) 526-8104                ||||      ||||
% email: [email-masked]       CCIE #2100      ..:||||||:..:||||||:..
%
%
%

---

From: "Michael H. Lambert" <[email-masked]>
Date: Fri, 01 Nov 2002 20:47:20 -0500

--On Friday, 1 November 2002 18:44 -0500 Aldrin Isaac 
<[email-masked]> wrote:

[...]

> (2) have one site-local address

[...]

That should be one site-local address per interface...  Which leads to the 
observation that, although this WG is chartered with tackling the problem 
of SITE multihoming, a site MH solution which is also applicable to the 
enterprise interior is probably better than one which doesn't.

Michael

+-----------------------------------------------------------------------+
| Michael H. Lambert, Network Engineer           Phone: +1 412 268-4960 |
| Pittsburgh Supercomputing Center               FAX:   +1 412 268-8200 |
| 4400 Fifth Avenue, Pittsburgh, PA  15213       [email-masked]        |
+-----------------------------------------------------------------------+