Subject: Re: getting IPv6 space without ARIN (Re: PAT )

From: [email-masked] (Sean Doran)
Date: Thu, 17 Aug 2000 18:07:29 +0200 (CEST)

Brian Carpenter writes -

| Please, please, nobody ever pick a prefix at random. 

Why not?  The chances of collision are quite small.  Moreover, in
the event of collision, IPv6 is supposed by design to facilitate
automatic renumbering, so moving to another prefix should be easy, right?
That's the hype.

Also, since automatic configuration and extra addresses in hosts
and routers is part of the IPv6 multihoming architecture, then
surely when there *IS* a TLA from which addresses percolate down,
surely the easy renumbering and ease of identifying which addresses
to prefer and which to deprecate -- stuff we hear is among the great
features of IPv6, incidentally -- means there is nearly no penalty
for having chosen a random prefix in the first place.   

Therefore, shouldn't you (as an IPv6-Lover) be saying:

| Your prefix should *always* come from your upstream provider

"Your prefix should *eventually* come from your upstream providers,
when and if you acquire them"?   Or am I missing something fundamental?

	Sean.

---

From: Daniel Senie <[email-masked]>
Date: Thu, 17 Aug 2000 12:32:34 -0400

> automatic renumbering, so moving to another prefix should be easy, right?

Those who fail to learn from history...

> when and if you acquire them"?   Or am I missing something fundamental?

What'd be better is for SOME organization, perhaps IANA, setting up one
provider-sized block of addresses for early adopters to USE.

Here's where the general wisdom that we should all shift to IPv6 meets
the reality that SOMEONE has to ante up and provide a way for folks to
start really working with the protocol, with REAL and routable
addresses.

The policies and procedures as the Internet grew (policies forged by
IETF, IANA and the realities of what was wrought) helped foster NAT. IP
address space was treated as a scarce commodity, so people found ways to
avoid wasting it. Now we're telling them to reinvest in a better way
with IPv6, and there's understandable resistance to betting on it. Of
course the lack of IPv6 stacks on many environments isn't helping
matters either.

Someone's going to have to find a way to break this logjam, or we'll be
stuck with the IPv4 world and layers of NAT/NAPTs forever. Breaking this
logjam won't happen at the IETF/IAB/IESG level. It'll happen through the
actions of IANA, ARIN/RIPE/APNIC, and it'll happen if a large ISP
decides it's the right thing for the Internet community.

-- 
-----------------------------------------------------------------
Daniel Senie                                        [email-masked]
Amaranth Networks Inc.                    http://www.amaranth.com

---

From: [email-masked]
Date: Fri, 18 Aug 2000 02:10:24 +0900

>provider-sized block of addresses for early adopters to USE.

	how about this?  i will soon be submitting this to i-d editor.

itojun

Internet Engineering Task Force                 Jun-ichiro itojun Hagino
INTERNET-DRAFT                                   IIJ Research Laboratory
Expires: February 17, 2001                               August 17, 2000

                 Guidelines for IPv6 local experiments
               draft-itojun-ipv6-local-experiment-00.txt

Status of this Memo

This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.

Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups.  Note that other groups
may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time.  It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as ``work in progress.''

To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html.

Distribution of this memo is unlimited.

The internet-draft will expire in 6 months.  The date of expiration will
be February 17, 2001.

Abstract

The memo defines how a (IPv6-wise) disconnected network should conduct
local IPv6 experiment.  The document tries to give guidelines for novice
IPv6 experimenters, and tries to help them from falling into common
pitfalls.

1.  Problem space

There are potential IPv6 users who would like to perform experiments
locally, in their IPv6 network disjoint from the worldwide IPv6 network
at large (or 6bone).

Site-local address [Hinden, 1998] could be used where appropriate.
However, site-local address has several operational differences from
global address (like below), and it is harder for novice users to
configure site-local address right than global address.  Also, due to
the differences, some of the things the user learnt from local
experiments may not be directly relevant when they get connected to the

HAGINO                 Expires: February 17, 2001               [Page 1]


DRAFT                    IPv6 local experiments              August 2000

worldwide IPv6 network - it reduces usefulness of their local
experiments.

o Site-local addresses are "scoped" address, while global addresses are
  not.

o Configuration must correctly identify site border routers.  This is an
  additional requirement.

o There are proposals on scoped routing exist [Deering, 2000] , however,
  implementation status is still rather disappointing.

For experiments over single link, link-local address could be used.
However, again, link-local address is a scoped address, and has radical
operational differences from global IPv6 (or IPv4) address.

2.  Recommendations

First of all, do not cook up IPv6 prefix on your own.  You cannot pick
random prefix number, that can jeopadize the whole point of experiment.

Next, it is recommended to use global addresses for early stage of
experiments.  As presented in the previous section, scoped (site-
local/link-local) IPv6 addresses have different operational
characteritics from global IPv6 addresses.  In the later stage of
experients, you may want to play with scoped addresses, and try to
understand how they behave.

2.1.  A site with 6bone site/IPv6 ISP nearby

If it is possible, try to contact nearest upstream 6bone site, or
upstream ISP, to give you an IPv6 prefix.  By getting IPv6 address space
properly, the site will have less problem when they get conneted to the
worldwide IPv6 network.  The address space can (supposedly) be used for
future IPv6 upstream connectivity.

2.2.  A site with global IPv4 connectivity

Whenever the site has a global IPv4 address with it, the site should use
the 6to4 IPv6 address prefix [Carpenter, 2000] derived from the IPv4
address space, for local experiments.  The prefix will be
2002:xxyy:zzuu::/48, where "xxyy:zzuu" is a hexadecimal notation of an
IPv4 global address that belongs to the site.  For detailed discussion,
please refer to 6to4 document.

2.3.  Completely disconnected site

If the site has no permanent global IPv4 address with it (like dialup
customer site), the site has two choices.

HAGINO                 Expires: February 17, 2001               [Page 2]


DRAFT                    IPv6 local experiments              August 2000

o The site may use site local address space.  The operation needs great
  care as presented above.

o The site may use the address prefix: 3ffe:0501:ffff::/48.  The address
  prefix was curved out from WIDE 6bone prefix.  The site MUST be
  renumbered, before the site gets connected to the worldwide IPv6
  network.

In both cases, the assigned prefix MUST NOT be advertised to the
worldwide IPv6 network, from anywhere.

2.4.  Other comments

If there are multiple administrative domains in the site, the site is
responsible for its internal coordination (the draft cannot solve your
local politics).

3.  Security considerations

The document talks about no security issues.

References

Hinden, 1998.
R. Hinden and S. Deering, "IP Version 6 Addressing Architecture" in
RFC2373 (July 1998). ftp://ftp.isi.edu/in-notes/rfc2373.txt.

Deering, 2000.
S. Deering, B. Haberman, and B. Zill, ""IP Version 6 Scoped Address
Architecture"," internet draft (March 2000). work in progress material.

Carpenter, 2000.
Brian Carpenter and Keith Moore, "Connection of IPv6 Domains via IPv4
Clouds without Explicit Tunnels" in draft-ietf-ngtrans-6to4-06.txt (June
2000). work in progress.

Change history

None.

Acknowledgements

The draft was written based on discussions with Japanese IPv6 users, and
help from WIDE research group.

HAGINO                 Expires: February 17, 2001               [Page 3]


DRAFT                    IPv6 local experiments              August 2000

Author's address

     Jun-ichiro itojun HAGINO
     Research Laboratory, Internet Initiative Japan Inc.
     Takebashi Yasuda Bldg.,
     3-13 Kanda Nishiki-cho,
     Chiyoda-ku,Tokyo 101-0054, JAPAN
     Tel: +81-3-5259-6350
     Fax: +81-3-5259-6351
     Email: [email-masked]

HAGINO                 Expires: February 17, 2001               [Page 4]

---

From: "Matt Crawford" <[email-masked]>
Date: Thu, 17 Aug 2000 12:11:44 -0500

> provider-sized block of addresses for early adopters to USE.

Hey, great idea!  RFC 2471:

   This document describes an allocation plan for IPv6 addresses to be
   used in testing IPv6 prototype software.  These addresses are
   temporary and will be reclaimed in the future.  Any IPv6 system using
   these addresses will have to renumber at some time in the future.
   These addresses will not to be routable in the Internet other than
   for IPv6 testing.

> Those who fail to learn from history...

Or from the present ...

---

From: Thomas Narten <[email-masked]>
Date: Thu, 17 Aug 2000 15:09:48 -0400

Sean,

Spamming the ietf list is bad form.

Trolling is no more appropriate.

Please take this elsewhere.

Thomas

---

From: "David R. Conrad" <[email-masked]>
Date: Thu, 17 Aug 2000 12:16:31 -0700

Daniel,

> Those who fail to learn from history...

Very true.  How many prefixes are in the swamp?

> provider-sized block of addresses for early adopters to USE.

Unless you are purposely trying to create a new (potentially *much*
larger) swamp, causing v6 to run into the _exact same_ routability
issues that exist with v4, setting aside a block for "early adopters"
would seem to be a move in exactly the wrong direction.

As Brian said, get address space from your upstream provider.  If your
provider doesn't support v6, find another.  If you can't find another
then get used to and deal with the fact that you will have to renumber.

> start really working with the protocol, with REAL and routable

Routability is defined by service providers, not TLA allocation
registries.  The allocation registries merely define uniqueness,
something that does not matter if you are not connecting to the
Internet.
 
Rgds,
-drc

---

From: Daniel Senie <[email-masked]>
Date: Thu, 17 Aug 2000 15:40:25 -0400

> Very true.  How many prefixes are in the swamp?

Actually, the lesson I was thinking of was the number of people who
built networks using Sun Microsystems' prefix, since that's what was in
the documentation. How many folks spent time remapping address spaces to
IANA assigned space or RFC 1918 space later? Picking your own prefixes
is a sure way to ENSURE you'll never talk to other sites. Even if you
use a NAT to get outside, you'll find it rather difficult to talk to
whatever site legitimately has the IP address block you randomly picked.

> would seem to be a move in exactly the wrong direction.

If upstreams aren't going to provide space, then a VIRTUAL upstream
should be created.

> then get used to and deal with the fact that you will have to renumber.

Everyone will expect to renumber somewhere along the line. That's not
the issue. Having REAL, INTEROPERABLE addresses is the issue. You think
MediaOne is in a rush to offer IPv6 on the cable modem plant? They
haven't figured out how to handle what they've got, and don't know how
to do multicast, why would they get to IPv6?

> something that does not matter if you are not connecting to the

OK. Here's what I'm proposing. For all the sites in the world who'd LIKE
to be able to have an upstream to provide IPv6, but for whom such
doesn't exist, and probably won't for a long time, some one or few
organizations should look into buying a block of IPv6 space, setting up
a few routers which can handle lots of tunnels, and build a virtual IPv6
upstream. Yes, they can even charge money for this and if it's not
outrageously expensive, folks might even find it useful.

The key factors required are that the users have a way to get real
addresses allocated properly, and that it be possible to successfully
talk to any other IPv6 host that's connected to ANY provider which has
begun IPv6 deployment.

---

From: [email-masked]
Date: Thu, 17 Aug 2000 16:35:53 -0400

> > when and if you acquire them"?   Or am I missing something fundamental?

Odd.. I didn't read it as a troll.  I read it as Sean asking Brian to
explain exactly how the "then the magic happens" part of prefix allocation
is supposed to happen.

Personally, I see a major swamp of private 6-over-4 tunnels between
early implementors just WAITING to happen.  It;'s not bad if there's 2 or 3
or 5 sites, but it's just a tad more then O(n)... ;)

-- 
				Valdis Kletnieks
				Operating Systems Analyst
				Virginia Tech

---

From: Sean Doran <[email-masked]>
Date: 17 Aug 2000 22:39:48 +0200

At the risk of having an Internet AD accuse me of SPAMming or trolling...

"David R. Conrad" <[email-masked]> writes:

> As Brian said, get address space from your upstream
> provider.  If your provider doesn't support v6, find
> another.  If you can't find another then get used to and
> deal with the fact that you will have to renumber

Here's what I am lost with.

I thought that when one connects to an IPv6 provider,
one's border router automatically acquires a range of
addresses from that provider, which it then parcels out to
other internal routers and/or hosts.

That is, _number acquisition_ is fully automatic.

Moreover, as noted in [SELECT] IPv6 hosts and routers can
have multiple addresses per interface, thus allowing any
new prefix to coexist with the old one.   The trick is
to make sure that the (source,destination) tuple chosen
for a conversation is selected optimally.

It was asserted to me very vigorously in Pittsburgh that
the border router could instruct "inside" hosts & routers
to deprecate or prefer addresses, depending on topology,
effectively as a tool to control routing policy decisions
made on end systems.

Ignoring the problems of an explosive number of
per-interface addresses, highly complicated [SELECT]
policies, the difficulty of helping hosts optimize their
routing decisions, and having sessions survive the
disappearance of direct connectivity to a v6 upstream, or
having subnets deal with dynamicism, this at first glance
seems to make it very simple to start testing out site v6
connectivity.  "One just connects to an upstream".

From time to time I run into the "you will have to
renumber" comment (it's not just you David), and wonder
about the validity of that, or whether my understanding of
how it's supposed to work is at variance with how it
really does (or will).  I get flavours of that uncertainty
too from various comments about acquiring addresses here
and there, even from people who are v6-informed.  (Indeed,
that is at the root of my question about, "who cares if
the addresses used by unconnected persons are random, or
about the renumbering burden when the connect?")

If the _acquisition_ of a range of IPv6 prefixes _ALWAYS_
matches the real-or-virtual topology, and the
_acuqisition_ is automatic and non-disruptive, then IPv6
has done something very different from IPv4.  In fact, the
trade off here is fewer globally visible prefixes
introduced in support of additional inter-entity
connectivity for some scaling issues concerning the
_removal_ of connectivity and more importantly the rate of
change of connectivity between subnets and their
topological parents.

> something that does not matter if you are not connecting to the

... and something which should not hurt you when you
connect to the v6 Internet for the first time.

        Sean.

---

From: "David R. Conrad" <[email-masked]>
Date: Thu, 17 Aug 2000 14:26:47 -0700

Daniel,

> For all the sites in the world who'd LIKE
> upstream. 

I'm sorry if I was unclear.  I was speaking of IPv6 network topology
when I was saying "upstream provider", regardless of whether that
provider is using native IPv6 or tunnels or whatever.  The ISP providing
the service provider endpoint of the tunnel should allocate space to
their customer, even if that customer is getting to them via a tunnel
through another ISP.

I'm surprised this isn't already on the service menu of those ISPs that
have begun deploying IPv6...

Rgds,
-drc

---

From: "Stephen Sprunk" <[email-masked]>
Date: Thu, 17 Aug 2000 18:28:59 -0500

Thus spake "David R. Conrad" <[email-masked]>
> Very true.  How many prefixes are in the swamp?

While we've learned from the experience with the swamp, we've also
learned that non-portable addresses can't be the *only* type available.
You can't simply banish multihoming by fiat, as much as current registry
policies are geared to do so.

> would seem to be a move in exactly the wrong direction.

Giving a single prefix to each AS would not create a "swamp" in the same
sense we have today.  A world with 65,536 IPv6 routes would hardly be
unmanageable -- it's far better than where we're at today with IPv4.

> then get used to and deal with the fact that you will have to
renumber.

Provided you're single-homed, that's a great plan.  IPv6 renumbering is
a reasonable task, provided it's not done too frequently.

> registries.

Indeed.  The "TLA allocation registries" then should have no prohibition
on allocating prefixes which the service providers may or may not route
in the future.  Providing a warning message is probably suitable,
however.

The problem here is that the TLA/SLA system is unrealistic when end
sites become multihomed.  Without portable addresses, multihoming simply
does not work in a reasonable fashion.

If there is no means for multihomed end sites to get portable addresses,
that makes IPv6 inferior to IPv4 for practical use.  It will be
extremely difficult to convince people to "upgrade" to a new protocol
which supports less functionality than the one they're using today.

> The allocation registries merely define uniqueness,

Uniqueness is mandatory for any two organizations connecting together,
even if they don't connect to the Internet itself.  Trying to allocate
private addresses between N parties partially meshed to each other is a
simple task when N is small, but the nature of the beast is that N grows
very quickly.  Without a registry allocating unique addresses, we'll end
up with NAT all over again.

> -drc

S

     |          |         Stephen Sprunk, K5SSS, CCIE #3723
    :|:        :|:        Network Design Consultant, GSE
   :|||:      :|||:       14875 Landmark Blvd #400; Dallas, TX
.:|||||||:..:|||||||:.    Email: [email-masked]

---

From: "David R. Conrad" <[email-masked]>
Date: Thu, 17 Aug 2000 17:06:17 -0700

[I suspect this should probably go over to ipng or something, so this'll
be my last post]

> You can't simply banish multihoming by fiat

Wouldn't think of it (always thought the arguments that multi-homing to
different providers wasn't necessary were unrealistic).

But I thought the official solution to multi-homing in v6 was an
(provider allocated) address per interface.  I will admit I haven't been
following this too closely.  Which document(s) did I miss?

> The "TLA allocation registries" then should have no prohibition
> in the future.  

If you look at the allocation policies, I think you'll find that this is
the case.

Of course, using this approach, there should be no swamp under v4
either.  

> Without a registry allocating unique addresses, we'll end

I would argue that without transparent from the end user's perspective
(not easy, transparent) renumbering you will never get away from NAT.

Tnx,
-drc

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 18 Aug 2000 10:02:27 -0500

> [I suspect this should probably go over to ipng or something, so this'll

Yes. 
> following this too closely.  Which document(s) did I miss?

There are multiple solutions or proto-solutions, including the ones
that we use for IPv4. But it's a hard problem (not because of IPv6
particularly - it's intrinsically hard). So it is an ongoing discussion
in the WG.

  Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 18 Aug 2000 10:09:13 -0500

Valdis,

[email-masked] wrote:
...
> or 5 sites, but it's just a tad more then O(n)... ;)

What do you mean?

Firstly "6 over 4" refers specifically to RFC 2529. Do you mean standard
IPv6 tunnels as per RFC 1933 and its pending update?

If so, what's the problem? We expect millions of those during v6/v4 coexistence.
Why is that a swamp, assuming people get their prefixes from upstream?

  Brian

---

From: Michael Richardson <[email-masked]>
Date: Fri, 18 Aug 2000 12:56:23 -0400

>>>>> "Valdis" == Valdis Kletnieks <[email-masked]> writes:
    Valdis> Personally, I see a major swamp of private 6-over-4 tunnels
    Valdis> between early implementors just WAITING to happen.  It;'s not bad
    Valdis> if there's 2 or 3 or 5 sites, but it's just a tad more then
    Valdis> O(n)... ;)

  If we *DON'T* create this swamp, then we won't have enough IPv6 experts to
force deployment. This is a serious chicken and egg situation. 

   :!mcr!:            |  Solidum Systems Corporation, http://www.solidum.com
   Michael Richardson |For a better connected world,where data flows faster<tm>
 Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html
	mailto:[email-masked]	mailto:[email-masked]

---

From: Tim Salo <[email-masked]>
Date: Tue, 22 Aug 2000 11:03:25 -0500 (CDT)

> To: [email-masked] (Sean Doran)
> Subject: Re: getting IPv6 space without ARIN (Re: PAT )
> Date: Thu, 17 Aug 2000 15:09:48 -0400
> From: Thomas Narten <[email-masked]>
>
> Sean,
>       [...]

Sean does have a habit of asking questions that highlight the fact that
IPv6 isn't ready for wide-spread production deployment.  I understand that  
you might you might not want to be reminded of this situation, but I believe
that your response (particularly as an IETF area director) is
inappropriate.

A more appropriate response might be to aggressively promote IPv4/IPv6
migration at IETF meetings.  You might:

o	Coordinate an IPv6 migration help desk at the IETF that will
	help attendees upgrade their laptops to run IPv6,

o	Run IPv6 (only) on the desktop machines at the IETF,

o	Publish traffic statistics that compare the volume of IPv4
	versus IPv6 usage at the IETF meetings,

o	Set an objective for when the IPv6 traffic is at least as great
	as IPv4 traffic at IETF meetings, and

o	Set an objective for when IETF meetings will support only
	IPv6.

If you can point me to a production-quality Windows 98 IPv6 stack,
I would be happy to try to install it on my laptop, and maybe even
run it at the next IETF meeting and help you with your migration
project.  (Oh, and make sure wireless works.)

Of course, I have been accused of being a counter-revolutionary for
making these sorts of suggestions...

-tjs

---

From: Thomas Narten <[email-masked]>
Date: Wed, 23 Aug 2000 07:30:36 -0400

> IPv6 isn't ready for wide-spread production deployment.

While I welcome Sean's input as a backbone operator, his long-running
disdain for IPv6 is also well known.  Perhaps my previous response was
a bit hasty from this perspective. Saying more only invites further
misinterpretation.

What this thread has made clear is that there continues to be a need
for more education about what IPv6 does and does not do. One of the
things that inhibits the overall discussion and accentuates the gulf
between the two communities, is folks claiming IPv6 does X (which it
does not do, or is an *option* rather than a *requirement*) and then
proceeding to begin discussion based on a faulty premise. Earlier
postings assuming trivial and automatic renumbering in IPv6 are one
example. Another is implying that IPv6 has a "new multihoming model"
that replaces (as opposed to supplementing) the existing models used
in IPv4, even in cases where the IPv4 approach would appear to work
fine. (It is probably worth noting that in the case of multihoming, it
is far from clear that the current approaches used in IPv4 will scale
properly, hence the reason for pursuing additional approaches in
IPv6). It's also worth reiterating that multihoming work in IPv6 is
still an on-going effort, and more input (especially from operators is
needed). I encourage interested persons to join the ipng mailing list
and participate.

Finally, the ietf list is really not the best place to have a serious
technical discussion about IPv6 shortcomings. I know of IPv6 experts
who aren't subscribed to this list.

> o	Set an objective for when IETF meetings will support only

Some of these suggestions have merit, and I believe that help has been
available at IETF meetings (though perhaps not well advertised) for
those that want to run IPv6. (IPv6 services have been available at
IETF meetings for some time -- if you have an IPv6 enabled on your
laptop, it just works.) On the other hand, setting an objective for
when IETF meetings support IPv6 only is unrealistic. IPv6 will take
decades to completely displace IPv4. Also, the hard issues about
disabling IPv4 at an IETF (which is what I interpret your suggestion
of IPv6-only above to be) only works when all the end sites that
IETFers communicate with are IPv6-enabled. We have little control over
that.

Thomas

---

From: Bob Hinden <[email-masked]>
Date: Wed, 23 Aug 2000 07:28:00 -0700

Tim,

>project.  (Oh, and make sure wireless works.)

What I did on my laptop was to upgrade to Win2K and then install the 
Microsoft IPv6 package ( 
http://msdn.microsoft.com/downloads/sdks/platform/tpipv6.asp ).  My 
experience is that it is very stable (Win2K and IPv6) and works over my 
wireless card.

Bob