Subject: Fwd: I-D ACTION:draft-hinden-ipv6-global-local-addr-01.txt

From: Bob Hinden <[email-masked]>
Date: Fri, 13 Jun 2003 14:24:45 -0700

FYI.  Changes include:

       o Added section on scope definition and updated application
         requirement section.
       o Clarified that, by default, the scope of these addresses is
         global.
       o Renumbered sections and general text improvements
       o Removed reserved global ID values
       o Split Global ID values into centrally assigned and local
         assignments and added text to describe local assignments
       o Added pseudo code for local allocation submitted by Brian
         Haberman and added him as an author.

The draft continues the use of the FC00::/7 prefix as I didn't see (as the 
author) a clear consensus to change it.

Bob

>To: IETF-Announce: ;
>From: [email-masked]
>Reply-to: [email-masked]
>Subject: I-D ACTION:draft-hinden-ipv6-global-local-addr-01.txt
>Date: Fri, 13 Jun 2003 07:51:35 -0400
>
>A New Internet-Draft is available from the on-line Internet-Drafts 
>directories.
>
>
>         Title           : Globally Unique IPv6 Local Unicast Addresses
>         Author(s)       : R. Hinden
>         Filename        : draft-hinden-ipv6-global-local-addr-01.txt
>         Pages           : 13
>         Date            : 2003-6-12
>
>This document defines an unicast address format that is globally
>unique and is intended for local communications, usually inside of a
>site.  They are not expected to be routable on the global Internet
>given current routing technology.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-hinden-ipv6-global-local-addr-01.txt
>
>To remove yourself from the IETF Announcement list, send a message to
>ietf-announce-request with the word unsubscribe in the body of the message.
>
>Internet-Drafts are also available by anonymous FTP. Login with the username
>"anonymous" and a password of your e-mail address. After logging in,
>type "cd internet-drafts" and then
>         "get draft-hinden-ipv6-global-local-addr-01.txt".
>
>A list of Internet-Drafts directories can be found in
>http://www.ietf.org/shadow.html
>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
>Internet-Drafts can also be obtained by e-mail.
>
>Send a message to:
>         [email-masked].
>In the body type:
>         "FILE /internet-drafts/draft-hinden-ipv6-global-local-addr-01.txt".
>
>NOTE:   The mail server at ietf.org can return the document in
>         MIME-encoded form by using the "mpack" utility.  To use this
>         feature, insert the command "ENCODING mime" before the "FILE"
>         command.  To decode the response(s), you will need "munpack" or
>         a MIME-compliant mail reader.  Different MIME-compliant mail readers
>         exhibit different behavior, especially when dealing with
>         "multipart" MIME messages (i.e. documents which have been split
>         up into multiple messages), so check your local documentation on
>         how to manipulate these messages.
>
>
>Below is the data which will enable a MIME compliant mail reader
>implementation to automatically retrieve the ASCII version of the
>Internet-Draft.
>Content-Type: text/plain
>Content-ID:     <[email-masked]>
>
>ENCODING mime
>FILE /internet-drafts/draft-hinden-ipv6-global-local-addr-01.txt
>
><ftp://ftp.ietf.org/internet-drafts/draft-hinden-ipv6-global-local-addr-01.txt>

--------------------------------------------------------------------
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: "Michel Py" <[email-masked]>
Date: Tue, 17 Jun 2003 09:53:50 -0700

Brian,

> If you are correct, exactly the same will happen with
> PA space.

[I assume that you are referring to jj's proposal]

In the "putting the RIRs out of business" dept, no (because LIRs would
still pay to obtain PA space).

In the "explosion of the routing table" dept, the risk is a lot lesser
for three reasons:

- No matter what the "guarantees" that a LIR would give about the
allocating permanently a block to a site, it still remains PA which
means that the incentive to get it routed globally is not nearly as
strong.

- NRENs and some other organizations will likely continue filtering long
PA prefixes.

- In case a LIR provides addresses and not transit, they will likely
blackhole the block they allocated to that purpose (because of economic
reasons, not because the IETF says so), making routing longer prefixes
within that block moot.

In other words:
- There is a strong and unfulfilled demand for globally routable PI.
- Neither Bob or jj's proposals are aimed at providing it. However,
- jj's proposal does not make it as globally routable PI. Simply does
not work. Yes it could eventually be perverted into that, but as the
"consumer" I am not buying it as a good enough PI solution.
- There is nothing that stands between Bob's proposal and the PI swamp
except an IETF edict that says "don't do it because it's the wrong thing
to do" which does not stand against any money argument.

As we have seen with the Elz appeal recently, it is none of the IETF's
business to prevent users to misconfigure networks nor to force vendors
to release products that can't be misconfigured.

Michel.

---

From: "Michel Py" <[email-masked]>
Date: Tue, 17 Jun 2003 10:39:34 -0700

kre,

| Michel Py wrote:
| $2.5k/year is enough for ISPs to leak it.

> Robert wrote:
> But why would any other ISP accept it? 

Because they would be under pressure from their own customers to do so,
as well as announcing their own customer's prefixes to others. We are
not talking about one guy corrupting one ISP here. EVERYONE (well, lots
of people) wants PI, so all ISPs are in the same boat. All it takes is
two or three of them to do it, then a few complaints from customers to
other ISPs that don't do it yet that they can't reach a site and voila
we've opened the floodgates.

Michel.