Subject: RE: GUSL proposal (very crude)

From: "Michel Py" <[email-masked]>
Date: Thu, 28 Nov 2002 11:07:17 -0800

Alan,

Thanks for your comments.

> The three allocation types may be broader in scope
> that the _minimum_ requirements, but, to quote Mae
> West: "too much of a good thing can be wonderful."

Note (as mentioned earlier) that the third type is subject to scrap at
any time, including if the rest of the text reaches consensus, in order
to expedite the process.

> Since we are already dealing with a /10 block for the entire
> SL space, this yields a maximum of 2**38 allocatable prefixes.
> I am impelled to wonder aloud: is this a sufficient count of
> possible allocations to meet the anticipated demand over the
> expected life of the IPv6 protocol?

The answer to this question is likely yes. Comparing scalability with
another topic which is multihoming, we have designed the number of
multihomed sites around 2**32 (4 billion). Although we would have the
possibility to allocate another /16 for multihomed sites should the need
arise, please keep in mind that:
- Site-locals are not for everybody.
- 2**38 is 256 billion, of /48 sites with 64k subnets each this is.
There are 6 billion people on this planet today. I don't see the need
for more than 1 site per person, if that. If we get in a situation such
as massive colonization of outer space or Earth looking like Coruscant,
we will allocate another /10 for site-locals.

> Should we consider making the routing protocol requirement
> more general by substituting the specfication "any exterior
> gateway protocol" for the very specific "BGP"?

Good point, changed.

> a) GUSL addressing may not be assigned to links (private
> or otherwise) connecting two or more sites, even if the
> GUSL addresses are not routable over the public network; 
> or
> b) traffic bearing GUSL source or destination addresses
> may not be carried over links (private or otherwise)
> interconnecting two or more sites, even if the links
> themselves bear global addresses
> Based on previous traffic in the mailing list, I would
> expect that your intent would have been closer to the
> latter.  

Actually, both. I was thinking about replacing the text with:

3. Multiple sites:
   GUSL addresses MUST NOT be used for communication with
   other sites. Routers MUST NOT forward any packets with
   GUSL source or destination addresses outside of the site.

> I see potential implementation inconveniences with either
> interpretation above, but nothing that is insurmountable
> if a reasonable PI address allocation scheme for private
> network facilities is worked out before IPv6 begins to see
> widespread service in end-user networks.

Agreed.

Michel.

--------------------------------------------------------------------
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: "Christian Huitema" <[email-masked]>
Date: Thu, 28 Nov 2002 22:23:20 -0800

There is a sense of deja vu in all this discussion -- similar proposals of making SL more unique by somehow sticking an identifier in the 38 available bits have popped out every 2 years on the list since 1994; I have to plead guilty, since I have indeed been one of the proponents.
 
>       There is a need for three types of allocation:
>       - Free, automated configuration, no registration,
>         no external connection, almost unique.
>       - Free, manual or semi-automatic configuration,
>         no registration, Internet connection necessary
>         for semi-automatic configuration, unique.
>       - Fee-based, manual registration, unique.
>         Additonal properties TBD.

I don't understand the intermediate category, and specifically the implementation as:
 
>       1.2.2 Unregistered, free, unique, sequentially allocated.
 
Unique and sequential  is contradictory with unregistered. I understand that we could implement a web site that distributes sequential numbers, although it is not clear that we can run a web site that runs a strictly sequential counter efficiently; you will probably need to loosen the sequential requirement to allow for a parallel implementation. But in the absence of registration there is a big risk that poorly written implementations will get a new number each time they boot. In fact, there is also a big risk that a denial of service attack brings the system down. I would personally go for a simpler scheme: 1 bit for random/registered, and a controlled registration process to remove doubts. By the way, I would also probably reserve a /16 prefix for a special class of 32 bits identifiers, the alreday allocated  IPv4 addresses.
 
-- Christian Huitema

---

From: "Michel Py" <[email-masked]>
Date: Fri, 29 Nov 2002 10:23:44 -0800

Mark,

> Mark Smith wrote:
> Playing the devils advocate ....
> Michel, can you describe, in a real world, nuts and
> bolts manner, where your "site" boundary would be.

I have tried to address this in the GUSL draft (under co-author review,
link to be posted ASAP)

Follows is the tentative text.
Michel.

0. Meaning of "site"

   The word "site" appears to be understood differently by the
   community than it is loosely defined in [ADDRARCH]:
   
   > [ADDRARCH]
   > A "site" is, by intent, not rigorously defined, but is typically
   > expected to cover a region of topology that belongs to a single
   > organization and is located within a single geographic location,
   > such as an office, an office complex, or a campus.  A personal
   > residence may be treated as a site (for example, when the
   > residence obtains Internet access via a public Internet service
   > provider), or as a part of a site (for example, when the
   residence
   > obtains Internet access via an employer's or school's site)
   
   It appears that "site" is used by the community as a shorter form
   of "end site" as described in [IPV6ASSIGN]. By extension, "site"
   has largely been used as a synonymous of "/48" and assimilated to
   the administrative boundaries of the organization being assigned an
   end-site prefix.
   
   This document uses "site" having the same meaning as "end site" as
   described in [IPV6ASSIGN].

[ADDRARCH] Deering, S. and R. Hinden, "IP Version 6 Addressing
Architecture", http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-
addr-arch-v3-11.txt, October 2002.

[IPV6ASSIGN] APNIC, ARIN, RIPE-NCC, "IPv6 Address Allocation and
Assignment Assignment Policy", June 26, 2002.
ftp://ftp.cs.duke.edu/pub/narten/global-ipv6-assign-2002-06-26.txt

---

From: "Michel Py" <[email-masked]>
Date: Fri, 29 Nov 2002 10:24:26 -0800

Christian,

> Christian Huitema wrote:
> There is a sense of deja vu in all this discussion.

Indeed.

I think that one of the reasons former proposals have failed is because
there was no enforcement of non-routability in the public Internet, if
my memory is correct.

 
> Unique and sequential is contradictory with unregistered.

There is a difference between registered and centrally controlled. Both
require access to a server that guarantees uniqueness. Unregistered
means that the requester does not have to provide any information. I
thought about using "anonymous registration" but there is no info to
register. The sequential server would not keep track of registrations
for more than 24 hours, I think.

> it is not clear that we can run a web site that runs a strictly
> sequential counter efficiently; you will probably need to loosen
> the sequential requirement to allow for a parallel implementation.

This is easy, just split the address range reserved for this purpose for
multiple servers.

> But in the absence of registration there is a big risk that poorly
> written implementations will get a new number each time they boot.

I have addressed this in the draft to come. It's under co-author review
and I will post a link ASAP.

> In fact, there is also a big risk that a denial of service attack
> brings the system down.

Not that much of a big deal. DOS do not last forever. The case that uses
access to the GUSL server is manual configuration initiated by the
administrator. If the GUSL server is unreachable, the administrator can
settle for a hash generated prefix to get his network going and try
again the next day. Beside, the savvy administrator would have obtained
the prefix *before* configuring the router.

> I would personally go for a simpler scheme: 1 bit for
> random/registered, and a controlled registration process
> to remove doubts.

Problem is this won't be free, are there any takers to do it for free?

> By the way, I would also probably reserve a /16 prefix for a
> special class of 32 bits identifiers, the alreday allocated
> IPv4 addresses.

You mean, something like
FEFE:IPV4:ADDR:, similar to 6to4 mechanism?
It crossed my mind, what worries in doing this is that people will
hijack non-portable IPv4 addresses as well as legitimately using
portable ones.

Michel.

---

From: "Christian Huitema" <[email-masked]>
Date: Thu, 28 Nov 2002 22:23:20 -0800

-- Christian Huitema