Re: Why Scopes? (was: Re: [saad] About saad)

Ralph Droms <rdroms@cisco.com> Mon, 20 October 2003 20:40 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03739 for <saad-archive@odin.ietf.org>; Mon, 20 Oct 2003 16:40:29 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABgoy-0005eP-Dk for saad-archive@odin.ietf.org; Mon, 20 Oct 2003 16:40:09 -0400
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9KKe8Zx021715 for saad-archive@odin.ietf.org; Mon, 20 Oct 2003 16:40:08 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABgox-0005e8-EH for saad-web-archive@optimus.ietf.org; Mon, 20 Oct 2003 16:40:07 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03721 for <saad-web-archive@ietf.org>; Mon, 20 Oct 2003 16:39:57 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABgov-00001D-00 for saad-web-archive@ietf.org; Mon, 20 Oct 2003 16:40:05 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABgov-00001A-00 for saad-web-archive@ietf.org; Mon, 20 Oct 2003 16:40:05 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABgot-0005cf-HI; Mon, 20 Oct 2003 16:40:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABgoo-0005b8-OK for saad@optimus.ietf.org; Mon, 20 Oct 2003 16:40:00 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03710 for <saad@ietf.org>; Mon, 20 Oct 2003 16:39:48 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABgom-00000r-00 for saad@ietf.org; Mon, 20 Oct 2003 16:39:56 -0400
Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1ABgol-00000T-00 for saad@ietf.org; Mon, 20 Oct 2003 16:39:55 -0400
Received: from cisco.com (64.102.124.13) by sj-iport-5.cisco.com with ESMTP; 20 Oct 2003 13:40:44 -0700
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h9KKdLFQ016579; Mon, 20 Oct 2003 16:39:22 -0400 (EDT)
Received: from rdroms-w2k01.cisco.com (rtp-vpn2-575.cisco.com [10.82.242.63]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADH79417; Mon, 20 Oct 2003 16:39:18 -0400 (EDT)
Message-Id: <4.3.2.7.2.20031020163757.01e7e938@flask.cisco.com>
X-Sender: rdroms@flask.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 20 Oct 2003 16:39:15 -0400
To: Brian E Carpenter <brc@zurich.ibm.com>
From: Ralph Droms <rdroms@cisco.com>
Subject: Re: Why Scopes? (was: Re: [saad] About saad)
Cc: Michel Py <michel@arneill-py.sacramento.ca.us>, James Kempf <kempf@docomolabs-usa.com>, saad@ietf.org
In-Reply-To: <3F9430AA.275235C5@zurich.ibm.com>
References: <DD7FE473A8C3C245ADA2A2FE1709D90B06C66A@server2003.arneill-py.sacramento.ca.us>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Sender: saad-admin@ietf.org
Errors-To: saad-admin@ietf.org
X-BeenThere: saad@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/saad>, <mailto:saad-request@ietf.org?subject=unsubscribe>
List-Id: Scope Addressing Architecture Discussion <saad.ietf.org>
List-Post: <mailto:saad@ietf.org>
List-Help: <mailto:saad-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/saad>, <mailto:saad-request@ietf.org?subject=subscribe>

draft-hain-templin-ipv6-limitedrange-02.txt should be read *and commented
on* - I don't think the draft is a finished product, yet, but it might
serve to focus our discussion...

- Ralph

At 08:59 PM 10/20/2003 +0200, Brian E Carpenter wrote:
>I think Michel is basically correct here. And I think that
>draft-hain-templin-ipv6-limitedrange-02.txt should be
>read at this point.
>
>    Brian
>
>Michel Py wrote:
> >
> > James,
> >
> > > James Kempf wrote:
> > > One of the things I'd like to see is a list of why people
> > > use scoped addresses (RFC 1918) in IPv4.
> >
> > I have some text about this, see below.
> >
> > Note: in the text below, the reason I state that some reasons are
> > actually non-reasons is because the motive behind the use of scoped
> > addresses (RFC1918) is _not_ their scoping but some other property of
> > RFC1918 addresses or because the motive is a by-product of some other
> > thing that results in RFC1918 addresses being used.
> >
> > Non-reason #1: "lots of addresses for free".
> > --------------------------------------------
> > This is why people have moved to NAT, not why people have moved to
> > RFC1918; the multiplication of addresses is a feature of NAT, and the
> > use of RFC1918 in this situation is only a by-product of the use of NAT
> > because it just happens that RFC1918 addresses are the best choice to
> > put behind NAT (compared to hijacking a random prefix).
> >
> > It is generally believed that if we do see IPv6 NAT, it will not be
> > because of address scarcity nor because ISPs would charge for a /48.
> > Similar to the reason "lots of addresses for free" is not why people use
> > RFC1918 (NAT is the reason), price, scarcity or unavailability of IPv6
> > PA addresses is likely not why people would want to use IPv6 scoped
> > addresses.
> >
> > Non-reason #2: Cheap alternative to PI/portable addresses.
> > ----------------------------------------------------------
> > I have _tons_ of customers that have no problem whatsoever obtaining
> > enough PA addresses for their needs. They won't get extra ones, but they
> > will get enough. Although it is true that for the home market obtaining
> > more than one static address is some extra money that could be spent on
> > something else, it is a non-existent issue for businesses; PA addresses
> > are typically good enough for home use.
> >
> > For small businesses that get low grade connectivity such as DSL, $20/mo
> > or $50/mo to get a /27 or a /26 is insignificant. For larger business
> > that get T1 and above connectivity, enough PA IPv4 addresses are
> > typically part of the deal with the ISP.
> >
> > So for businesses there are enough addresses, but these addresses are
> > not PI. In this situation, people use RFC1918 addresses because they are
> > portable, not because they are scoped. Here again the real reason is
> > NAT. The main driving force behind this is cost of renumbering is so
> > high that it offsets by far the annoyances of NAT; besides most
> > enterprises use a combination of public and private addresses.
> > Conservation of address space is here nothing more than an added bonus
> > of NAT, because businesses might not request as many public addresses as
> > they would have if they were not using NAT.
> >
> > Security/isolation/defense-in-depth.
> > ------------------------------------
> > This is a non-reason for the home market and a valid one for the
> > business/enterprise.
> >
> > For the home market: besides having more addresses (described above)
> > what the home user likes is the security provided by RFC1918 addresses.
> > Why do RFC1918 addresses provide security? Because they are not publicly
> > routable, so using those mandates NAT, which does provide a basic
> > firewall.
> >
> > In this case, scoping == not-publicly-routable. So, the home market uses
> > RFC1918 not because of their scope but because of the property they have
> > being not-publicly-routable, which means NAT, which means basic
> > firewall. Security could be provided with a non-NAT firewall, but since
> > NAT is already there because the home user wants multiple addresses and
> > the cheapest available firewall is a NAT box anyway, NAT it is.
> >
> > For the business/enterprise is where scoping comes to a use. In this
> > case, scoping != not-publicly-routable. There are perfectly valid uses
> > for publicly routable but nevertheless scoped addresses. In this
> > environment, the use of RFC1918 addresses provides both a fail-safe
> > against firewall/access-list SNAFUs, and a supplemental annoyance for
> > hackers. None of these are miracles, but are part of defense-in-depth
> > strategies and are palatable to the taste of the experienced enterprise
> > operators that do not like to have all the eggs in the same basket.
> > Also, network administrators like the comfort of this big 10/8 block.
> >
> > In short: why do people use scoped (RFC1918) addresses?
> > -------------------------------------------------------
> > Home users:
> > It has nothing to do with scoping and everything to do with NAT. The
> > home user wants a) more addresses for free and b) a basic firewall, both
> > of which are features of NAT not scoping. Usage of RFC1918 address is
> > only a by-product of NAT.
> >
> > Business/enterprise:
> > Part of it has nothing to do with scoping either. The #1 reason behind
> > using RFC1918 in a business environment is independence from the ISP /
> > easy renumbering.
> > The other part of it is where scoping takes place: automatic/fail-safe
> > access control (to be used in combination with manually configured
> > security) and an extra annoyance for the hacker (needs to tunnel out on
> > top of hacking).
> >
> > How does this apply to IPv6?
> >
> > Home users:
> > The number of address is solved. What is left to provide is a basic
> > firewall.
> > This brings the question whether or not this basic firewall should be a
> > feature of scoping or not. IMHO, these are two different topics, and
> > home usage does not care about scoping.
> >
> > Business/enterprise:
> > There is a need for scoping that is currently not fulfilled. This is the
> > same concept as IPv4 RFC1918 address, except that the reason for
> > non-global-routability should be the scoping mechanism opposed to
> > ambiguity for IPv4.
> >
> > Note that there also is a need for a PI equivalent that is not fulfilled
> > either and the lack of it leads us directly to NATv6.
> >
> > > Clearly, NATs are popular in IPv4 for reasons other than lack
> > > of address space, and simply condemning them as evil or even
> > > arguing against them without understanding why people want
> > > them isn't likely to result in a usable technical solution,
> > > and probably won't persuade people to stop using them anyway.
> >
> > Indeed; I hope the analysis above helps to clarify this.
> >
> > Michel.
> >
> > _______________________________________________
> > Saad mailing list
> > Saad@ietf.org
> > https://www1.ietf.org/mailman/listinfo/saad
>
>--
>- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>Brian E Carpenter
>Distinguished Engineer, Internet Standards & Technology, IBM
>
>NEW ADDRESS <brc@zurich.ibm.com> PLEASE UPDATE ADDRESS BOOK
>
>_______________________________________________
>Saad mailing list
>Saad@ietf.org
>https://www1.ietf.org/mailman/listinfo/saad


_______________________________________________
Saad mailing list
Saad@ietf.org
https://www1.ietf.org/mailman/listinfo/saad