draft-ietf-multi6-v4-multihoming-00.txt

[Kurt Erik Lindqvist <kurtis@kurtis.pp.se>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

	

I thought I had already sent a mail like this to the list but when I 
was curious as to why I didn't get any replies I realized that it never 
made it to the list. So here we go again.

Me and Brian have decided that I would update the above draft. For this 
work, Brian will be the chair.


I have gone through the list archive looking for comments and have made 
the list below of issues. I also know that more people have comments. 
Please send any additional comments to the list and I will try and get 
a updated version out soon.


Best regards,

- - kurtis -

Issue 1
Pekka Savola
2003-01-31

The draft lists the following:

3. Motivations for Multihoming
3.1 Redundancy
3.2 Load Sharing
3.3 Performance
3.4 Policy

I'd like to propose an additional item, "3.0 Independence".

It's only implicitly included under Policy, and technically (mostly)
included under redundancy.. but it seems to me that it is a major reason
for certain solutions, and a critical reason why many IPv6 site
multihoming solutions are not considered adequate.


=====

Issue 2
Pekka Savola
2003-01-31

3. Motivations for Multihoming

==> this section should be removed completely, as it is duplicated
in the multihoming goals document now.


====

Issue 3
Pekka Savola
2003-01-31

4. Features of IPv4 Multihoming

==> this document assumes a prior knowledge of what "*THE* IPv4
multihoming solution" is.  This has not been described anywhere.
So, I'd propose to add a new section to replace sect 3 to describe
a few common ways of doing it.  There should be enough meat here, as
I had 16 pages of analysis of current methods in my thesis about
site multihoming.

basically, I think you can divide the IPv4 multihoming techniques
to about five different types:

  1) multihoming using your own AS number and your own prefix,
     advertising them through multiple providers.

  2) multihoming using your own AS number, but advertising
     a more specific prefix from one of your ISPs.  Some of these
     are multihomers (the backup is through the ISP which announces
     the aggregate), some have just bought the prefix when they
     changed ISP.

  3) multihoming with your own prefix, but without your own (public)
     AS number.  As the cost of the AS is low, this is rather rare.
     The customer uses private AS numbers or the ISP proxy-advertises
     the prefixes.  Nondistinguishable from "origin theft" as multiple
     AS's seem to be originating the same prefix.

  4) multi-attaching multiple times to an ISP, even though not
     strictly multihoming, is also popular.  This is a very simple
     operation, and often the tradeoffs (unless you want independence
     as a multihoming motivation) are acceptable if you pick the right
     provider.

  5) employing NAT-based or RFC2260 -like solutions (you could also
     separate these two) to achieve at least some multihoming
     benefits.  Typically you cannot get everything, but for some,
     this has been enough.

In section 4, you've analyzed only 1).  This may be OK, as the
characteristics are similar with the other major method, 2).  But
this needs to be spelled out.  Another way would be analyzing each
of these in turn, or the like.

=====

Issue 4
Pekka Savola
2003-01-31


==> you should also include the analysis of the "additional features"
of the multihoming goals document wrt IPv4 multihoming, I guess?

=====

Issue 5
Pekka Savola
2003-01-31

==> the lists are also not up-to-date, as you don't list e.g. DNS or
packet filtering.


====

Issue 6
Pekka Savola
2003-01-31

6. Security Considerations

    Security considerations are not discussed in this draft.

==> this must be a flame-bait :), so replace it with something like:

    This memo analyzes the IPv4 multihoming practices.  This analysis
    only includes the description of the mechanisms and partially how
    they affect the availability of the site deploying the IPv4
    multihoming mechanism.  Other security properties of the IPv4
    multihoming mechanisms are not analyzed.


=====

Issue 7
Pekka Savola
2003-01-31

5. Limitations of IPv4 Multihoming

5.1 Scalability

==> I'd also add here something like:

    These mechanisms also add to the consumption of public AS number
    resources, when small sites wishing to multihome obtain an AS
    number specifically for only that purpose.  Using a different
    mechanism would help to conserve the 16-bit AS number space, and
    avoid the move to 32-bit AS numbers.


====

Issue 8
Pekka Savola
2003-01-31


==> throughout the document, one uses "enterprises" rather than "sites"
- -- is this intentional?



=====

Issue 9
Pekka Savola
2003-01-31

Abstract

    Multihoming is an essential component of service for enterprises [3]
    which are part of the Internet.  This draft describes some of the
    motivations, practices and limitations of multihoming as it is
    achieved in the IPv4 world today.

    The context for this discussion is the requirements analysis for site
    multihoming in IPv6, which is described in a companion draft [1].

==> the abstract must not include references



====

Issue 10
Pekka Savola
2003-01-31

2. Terminology

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
    document are to be interpreted as described in RFC 2119 [4].

==> these terms can be removed, they shouldn't be used in a document
like this anyway.



=====

Issue 11
Pekka Savola
2003-01-31

References

==> references need to split to informative and normative.

=====

Issue 12
- -------- Original Message --------
Subject: IPv4 multihoming limitations
Date: Sat, 3 May 2003 13:43:34 +0200
From: Iljitsch van Beijnum <iljitsch@muada.com>
To: Joe Abley <jabley@isc.org>
CC: Kurt Erik Lindqvist <kurtis@kurtis.pp.se>, multi6@ops.ietf.org

On vrijdag, mei 2, 2003, at 20:15 Europe/Amsterdam, Joe Abley wrote:

There are quite a few limitations for people that want to multihome in 
v4. Not everyone may be aware of those and subsequently underestimate 
the latent need for multihoming. So it might be good to document this 
after all.

I am still very happy to collate ideas and edit that document, if 
people are happy for me to do so.

Ok, here is some text:

The preferred way to multihome in IPv4 is to announce an independent
block of address space over two or more ISPs using BGP. Until the
mid-1990s this was relatively easy to accomplish, as the maximum
generally accepted prefix length in the global routing table was a /24,
and little justification was needed to receive a /24. However, in 1995
the growth of the global routing table became a problem once again, and
as a result Sprint decided to start filtering prefixes it accepted from
peers based on prefix length. This broke the expectation that a
multihomed network announcing a /24, regardless of where in the IPv4
address space this /24 was taken from, would be globally reachable.

Over the course of the next several years, filtering on Regional
Internet Registry allocation boundaries became accepted, if not
widespread, practice. As of the late 1990s the RIRs allocate address
space to those requesting it from them directly (mostly ISPs) in blocks
of at least a /20. The address space in 192.0.0.0/8 and part of
193.0.0.0/8 was allocated before CIDR was developed so it still
contains a large number of much smaller blocks. This part of the IPv4
address space is often called "the swamp". The networks that filter on
prefix length typically accept much larger prefixes from swamp space.

In the mean time, RIR address distribution policies became increasingly
more restrictive. The result of these two developments is that it is
nearly impossible for an non-ISP organization to obtain a large enough
block of address space to be sure its BGP announcement isn't filtered.
Multihomers are often forced to work around this by taking regular
provider aggregatable (PA) rather than the traditional
provider-independent (PI) address space from one of their ISPs and
announce this prefix to two ISPs. In theory, announcing this prefix to
the secondary ISP would be enough as reachability over the primary ISP
is assured by the aggregate this ISP announces. However, due to the
"longest match first" rule, traffic would exclusively flow over the
path with the longer prefix. So in practice the multihomer announces
the longer prefix both over the ISP that announces the aggregate and
over one or more secondary ISPs.

This practice has two advantages and one disadvantage for the
multihomed network. The first advantage is that they can obtain a much
smaller block of address space from an ISP than from a RIR. (Would-be
multihomers still often optimize their networks for qualifying for at
least a /24 by adopting accepted but relatively wasteful address
deployment strategies.) The second advantage is that even if their
announcement is filtered, they are still reachable over the primary ISP
by virtue of the aggregate announced by this ISP. Even when the circuit
to the primary ISP is down, this often works because the primary ISP
will generally accept the announcement over the secondary ISP, so
traffic flows from the filtering network to the primary ISP and then to
the secondary ISP in order to arrive at the multihomed network.

The disadvantage is that the multihomed network must depend on the
primary ISP for the aggregate. If the primary ISP goes down, this will
impact reachability to networks that filter. And when the multihomed
network leaves the primary ISP, they are generally expected to return
the address space because otherwise this ISP would have to route
traffic for a non-customer. Most ISPs will cooperate with this
"shooting holes in an aggregate" solution to multihoming, but some are
reluctant.





-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0.3

iQA/AwUBQLWdIKarNKXTPFCVEQKQlgCfd8pSi1Q/F87ncH55P//iNImC67AAoPcU
bnsKrl6Y0XkJv5XN0NRrNd2y
=evJc
-----END PGP SIGNATURE-----