Subject: RE: site local addresses (was Re: Fw: Welcome to the InterNAT...)

From: "Christian Huitema" <[email-masked]>
Date: Wed, 26 Mar 2003 18:55:12 -0800

Tony,

The specifics of the site local issue should be debated on the IPv6 WG
list, not on the global IETF list. Let me however respond to your point
regarding the quality of the debate, as I was the note taker during that
session.

My notes record that 22 separate speakers took part to this debate, some
coming to the microphone several time. It is also pretty clear from my
notes that the consensus of the room is evolving as the discussion
progresses, and as arguments are being exchange. Yes, there was mention
of "site local as a license to NAT", but there where many other
arguments: leakage through IP, DNS or application; the lack of
practicality of several restrictive models for site locals; the
possibility or not to use other solutions for isolated sites; and the
complexity of handling scoped addresses in applications. At the end, the
tally shows 20 hands rising in support of site locals, 102 hands rising
for their elimination.

In short, it was not a hasty discussion, there was an informed debate,
opinions evolved during the discussion, and a consensus was reached. I
believe that if you had been in the room you would feel closer to that
consensus.

-- Christian Huitema

---

From: "Stephen Sprunk" <[email-masked]>
Date: Wed, 26 Mar 2003 23:12:31 -0600

Thus spake "Christian Huitema" <[email-masked]>
> regarding the quality of the debate, as I was the note taker during that

Issues most often move to the IETF list when a vocal minority object to a
declaration of consensus by the WG chairs.  If the WG chair would like to
reopen the debate, I'm sure everyone will move back there.

> believe that if you had been in the room you would feel closer to that

I haven't seen anyone argue in favor of site-local addressing for the
purposes of having explicitly scoped addresses, so you are correct in one
sense.  What I am seeing is debate over private address space and NAT, which
many of us had expected site-locals to be useful for -- this email thread
(and the one on routing-discussion) belies any claims of consensus on that.

S

Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking

---

From: "Matt Crawford" <[email-masked]>
Date: Thu, 27 Mar 2003 09:08:04 -0600

> Yes, there was mention of "site local as a license to NAT", but
> there where many other arguments: leakage through IP, DNS or
> application; the lack of practicality of several restrictive models
> for site locals; the possibility or not to use other solutions for
> isolated sites; and the complexity of handling scoped addresses in
> applications. At the end, the tally shows 20 hands rising in
> support of site locals, 102 hands rising for their elimination.
> 
> In short, it was not a hasty discussion, there was an informed
> debate, opinions evolved during the discussion, and a consensus was
> reached.

This is so typical of the modern IETF -- 102 people were persuaded
by handwaving arguments that "something bad might happen" if a new
and useful technique were deployed, and they are being allowed to
overwhelm the 20 who were willing to dig in and find and solve any
real problems.

How many of your 22 speakers had implementation and deployment
experience to report?

---

From: "Jim Fleming" <[email-masked]>
Date: Thu, 27 Mar 2003 09:34:48 -0600

----- Original Message -----
From: "Matt Crawford" <[email-masked]>
> by handwaving arguments that "something bad might happen"

Imagine how much hand-waving 418 clueless people can do...
http://register.icann.org/cgi/attendees.cgi

...fortunately, 99.9% of the rest of the world can route around them via the InterNAT...

Jim Fleming
http://www.IPv8.info

Note: .GOV employees can make **purchasing decisions** about telecommunication protocols, they just can not spec them and develop
them and therefore warp the free markets in the United States of America.

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 27 Mar 2003 18:07:52 -0500

Hi Matt,

>overwhelm the 20 who were willing to dig in and find and solve any

I do not believe that your characterization is fair in this
case.  The discussion was thoughtful and informative, and we did
have several experts from different IETF areas involved, including
application developers, operators, routing experts, DNS experts,
etc.  I do not believe that group consensus was unduly influenced
by "handwaving arguments".

You didn't attend the meeting, and the minutes have not been
published yet. You are typically a very reasonable person, and I
am surprised at your willingness to characterize this meeting
so negatively, without any good source of information regarding what
actually happened...

>How many of your 22 speakers had implementation and deployment

The discussion of the appropriate usage of site-local addressing
in IPv6 has been taking place for several years.  There have been
numerous discussions in many forums, including multiple WG meetings
and several lengthy discussions (encompassing 1000's of messages) on
the IPv6 mailing list.   At least three internet-drafts have been
published on this subject, including our current scoped addressing
architecture, a draft that attempts to summarize the benefits and
issues associated with site-locals, and two proposals to limit
site-local addressing to specific usage cases.

Considerably more than 22 people have expressed an opinion on this
subject in the last 8 months alone, and these people have included
many people with real implementation and deployment experience,
as well as a vast array of experts in different technology areas.

No active IPv6 WG participant (whether or not he attends IETF
meetings) could credibly claim that he was unaware that this
discussion was taking place, or that he has been denied an
opportunity to voice his opinion on this subject (in-person, on
the mailing list, or both).  In fact, given the size and scope of
this discussion, there are probably very few IETF participants who
managed to miss the fact that this discussion has been taking place.

If you would like to express your technical opinion on the site-local
issue, I would suggest that you take it to the IPv6 WG mailing list.
I would be happy to continue a technical discussion with you on that
list.

We will be publishing the minutes to the IPv6 meeting soon and
checking all of the consensus points reached during our meetings
on the IPv6 list shortly.  Your input is definitely welcome.

Margaret

---

From: Keith Moore <[email-masked]>
Date: Thu, 27 Mar 2003 18:22:01 -0500

> overwhelm the 20 who were willing to dig in and find and solve any

uh, no.  102 people finally understood just how comprehensively broken
SLs are, and managed to finally overwhelm the 20 or so who were still in
compete denial about it.

Keith

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 27 Mar 2003 15:39:59 -0800

Hello folks,

I was there, and it wasn't so black and white.
It's not fair to characterize it so.

I suspect that most people there, who voted for
the elimination of site-locals, would still be
favor of enabling the features that site-locals
were intended to offer.  Perhaps the majority
position could be paraphrased as "against site-local,
but sorry to see them go".

My own vote was for elimination, but I think it
will be a mistake if there isn't a way for people
to get unique prefixes practically for free.

Regards,
Charlie P.

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 27 Mar 2003 15:49:51 -0800

Margaret Wasserman wrote:
> discussion was taking place,

The discussion has been about potential usage limitation, or BCP's
identifying application issues. The point of deprecation came out of
nowhere, and only occurred in the room in SF. This has not had valid
discussion.

Tony

>  or that he has been denied an 
> opportunity to voice his opinion on this subject (in-person, 
> on the mailing list, or both).  In fact, given the size and 
> scope of this discussion, there are probably very few IETF 
> participants who managed to miss the fact that this 
> discussion has been taking place.
> 
> If you would like to express your technical opinion on the 
> site-local issue, I would suggest that you take it to the 
> IPv6 WG mailing list. I would be happy to continue a 
> technical discussion with you on that list.
> 
> We will be publishing the minutes to the IPv6 meeting soon 
> and checking all of the consensus points reached during our 
> meetings on the IPv6 list shortly.  Your input is definitely welcome.
> 
> Margaret
> 
> 
> 
> 
> 
> 
> 
>

---

From: Keith Moore <[email-masked]>
Date: Thu, 27 Mar 2003 18:51:01 -0500

> but sorry to see them go".

I agree.  I think there was a general understanding that we need to
provide the capabilities that SLs were supposed to provide, but to do so
in other ways.

Keith

---

From: Tim Chown <[email-masked]>
Date: Fri, 28 Mar 2003 00:07:34 +0000

> provide the capabilities that SLs were supposed to provide, but to do so

Agree absolutely.

Erik made good points in SFO about desirable addressing properties for
customer networks (e.g. stable addressing).  That is one side of the issue.

The ipng list should be identifying the scenarios where networks require
addressing that would have otherwise have been supplied by site-locals,
and present viable alternatives.   For example, manets, intermittently
connected networks, and community networks with partial yet varied uplinks.
If these can be addressed (sic), then I think objections will diminuish.

As a side-note, a fifth SL option was presented "out of the blue" in SFO,
namely exclusive SL/global addressing (one or the other only), which,
because it was rather a "broken" idea, I think perhaps added to the room
sentiment that site-locals are broken (rightly or wrongly :)

Tim

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 27 Mar 2003 20:12:31 -0500

>nowhere, and only occurred in the room in SF. This has not had valid

There have been people calling for the complete removal of site-local
addressing all along.

And, elimination/deprecation was quite clearly raised as an option in
Atlanta.  At that time, we called for opinions on the following
options:  elimination, "limited", "moderate" or "full" usage, and
each of the four options had some support in that WG meeting.

Margaret

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 27 Mar 2003 17:26:09 -0800

Margaret Wasserman wrote:
> There have been people calling for the complete removal of 
> site-local addressing all along.
> 
> And, elimination/deprecation was quite clearly raised as an 
> option in Atlanta.  At that time, we called for opinions on 
> the following
> options:  elimination, "limited", "moderate" or "full" usage, 
> and each of the four options had some support in that WG meeting.

And in Atlanta we all agreed to take elimination off the list, and it
has not been discussed since. The agenda for SF was:
Site-Local Addressing
  Impact of site-local addressing -- Margaret Wasserman (20 min)
 
http://www.ietf.org/internet-drafts/draft-wasserman-ipv6-sl-impact-02.tx
t

  "Limited Usage" Summary -- Margaret Wasserman (5 min)
  [See appendix of draft-wasserman-ipv6-sl-impact-02, above.]

  "Moderate Usage" Proposal -- Bob Hinden (15 min)
 
http://www.ietf.org/internet-drafts/draft-hinden-ipv6-sl-moderate-01.txt

Nowhere in that or the mail preceding the meeting is elimination
mentioned. 

Tony

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 27 Mar 2003 20:40:34 -0500

Hi Tony,

I am not sure what your point is exactly, or why you want to make
this point on the full IETF list...

Are you suggesting that the options open to the IPv6 WG should
be constrained by the drafts that Bob and I list on the agenda?

By Thursday, the agenda had actually changed to a joint presentation
by me and Bob on the trade-offs between different site-local usage
options.

We also had a discussion section listed (on both the published
and final agendas) that you omitted, and during that discussion
the WG members in the room chose to reject the recommendations
that Bob and I had made, and they chose to deprecate site local
addresses.  Frankly, I was as surprised as you were.

Like all consensus reached in WG meetings, this consensus _will_
be confirmed on the list.  You will get your chance to express
your opinion there.  You have your chance, right now, to make
any arguments on the list that you think will persuade people
not to deprecate site-local addresses.

Unless you think that there is an issue here that is of wider
IETF interest, perhaps we could move this discussion to the IPv6
WG mailing list?

Margaret

---

From: Keith Moore <[email-masked]>
Date: Thu, 27 Mar 2003 23:32:32 -0500

> has not been discussed since.

what's changed is that we had a chance to look at various ways of limiting
usage of SL, and found that none of them would make SLs tolerable.

---

From: Keith Moore <[email-masked]>
Date: Thu, 27 Mar 2003 23:31:23 -0500

> sentiment that site-locals are broken (rightly or wrongly :)

well, it was something that hadn't been suggested yet, so I don't blame them
for trying.  but what became clear after looking at all of the different ways
of limiting usage of site local side-by-side is that every way of restricting
site locals still leaves us with a mess.  the only set of restrictions that
avoids leakage and/or requiring apps to be aware of network topology is to use
SLs only on isolated networks, and experience with RFC 1918 strongly indicates
that this doesn't work well in practice.

---

From: "Matt Crawford" <[email-masked]>
Date: Fri, 28 Mar 2003 08:46:49 -0600

> the elimination ...

At my first IETF meeting I received a T-Shirt, courtesy of Marshall
Rose, I believe, that said "We reject kings, presidents and voting..."

The real tragicomedy of this situation is that someone considered it
fitting and proper to count 102 hands.

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 28 Mar 2003 10:36:48 -0800

John C Klensin wrote:
> Tony,
> 
> I've been trying to get my mind around the various issues here, 
> and I keep getting back to the same place, so I think I need to 
> embarrass myself by making a proposal that I find frightening.
> 
> Let's assume, as I think you have suggested, that SL is all 
> about local addresses and filtering, and not about some special 
> prefix that applications need to recognize.  I'm still not sure 
> I believe that, but let's assume it is true and see where that 
> takes us.
> 
> Let's also remember the long path that got us to CIDR and 1918. 
> Our original position was that anyone using TCP/IP (v4) should 
> have unique address space.  I remember many discussions in which 
> people were told "don't just grab an address on the theory that 
> you would never connect. Our experience has been that, sooner or 
> later, you might connect to the public network, or connect to 
> someone else who has used 'private' (or 'squatter') space... 
> unique addresses will save you, and everyone else, a lot of 
> trouble".  In that context, 1918 and its predecessors came out 
> of two threads of developments:
> 
> 	* we were running short of addresses and wanted to
> 	discourage unconnected (or hidden) networks from using
> 	up public space and
> 	
> 	* we hoped that, by encouraging such isolated networks
> 	to use some specific address ranges, those ranges could
> 	be easily and effectively filtered at the boundaries.
> 
> We can debate how well either really worked, or what nasty 
> side-effects they caused, but probably it makes little 
> difference in the last analysis except to note that, no matter 
> what we do, leaks happen.
> 
> Now one of the problems IPv6 was supposed to solve was "too 
> little address space" or, more specifically, our having to make 
> architecturally bad decisions on the basis of address space 
> exhaustion.  I hope we have solved it.  If we haven't, i.e., if 
> the address space is still too small, then the time to deal with 
> that issue is right now (or sooner), before IPv6 is more broadly 
> deployed (and it better be variable-length the next time, 
> because, if we are conceptually running short of space already, 
> it would be, IMO, conclusive proof that we have no idea how to 
> specify X in "X addresses will be enough").
> 
> But suppose we really do have enough address space (independent 
> of routing issues).  In that context, is site local just a 
> shortcut to avoid dealing with a more general problem?  Should 
> we have a address allocation policy that updates the policies of 
> the 70s but ignores the intermediate "we are running out" steps? 
> Should I be able to go to an RIR and ask for unique space for an 
> isolated network, justify how much of it I need, and get it -- 
> with no promises that the addresses can be routed (and, 
> presumably, without pushing a wheelbarrow full of dollars/ 
> euros/ yen/ won/ yuan/...)?

The problems with this theory are that a registry costs money to run,
and it requires an organization to expose their business plan (never
mind figuring out who is really qualified to judge the validity of any
given justification). Even when the big bad US Gov. was picking up the
tab, there were cost control measures that required someone to validate
the request (I was one such sanity checker). If we create a space that
requires registration, it will become a simple -biggest wallet gets the
most space- arrangement, because it is in the financial interest of the
registry to accept all requests. The only push back to that is to set
the price per prefix high enough that the registry doesn't need more
cash to run, but that, and the recurring nature of those costs, will
cause people to avoid the registry and use random numbers. The other
point in this is that you can't force people to register until there is
a technical reason for it, like making routing work. 

> 
> Of course, this takes us fairly far onto the path of having to 
> think about multihomed hosts, not just multihomed LANs, but, as 
> others have pointed out, the notion of multiple addresses (or 
> multiple prefixes) for a given host (or interface) takes us 
> rather far down that path anyway.  Figuring out which address to 
> use is a problem we need to solve, with or without SL, or the 
> whole idea of multiple addresses on hosts, especially dumb 
> hosts, is going to turn out to be a non-starter.  And, as Louis, 
> Noel, and others have pointed out, it is hard.   But, if we can 
> find a solution, even one that is just mostly locally-optimal 
> and that fails occasionally, then it seems to me that your 
> position ultimately gives no advantages to a reserved site-local 
> form over unique, but non-routable, addresses.  The advantages 
> of the latter appear obvious, starting with being able to 
> identify the sources of address leaks and the notion that 
> routability is a separate negotiation with providers (and their 
> peers and other customers) and not an RIR responsibility.

Leaks are a multifaceted problem. On one hand it might facilitate
tracking the source of the leak, but on another it makes it impossible
for everyone to know that this specific prefix is supposed to be
filtered. While it might be nice to believe that defining a space as
non-routable means it won't be routed, reality is that ISPs that want to
survive will do what the paying customer says. The only defense against
route-for-hire table bloat is the technical infeasibility created by
ambiguity.

> 
> That would leave another topic which I consider separate: 
> whether we ought to create some number of 1918-like addresses 
> that organizations that are really isolated (not connected even 
> with other prefixes) can use without needing to have a 
> negotiation with an RIR.  The answer, I think, is probably 
> "yes", but it really is a policy question, not a technical one. 
> And, on the above model, an ISP offering service (and prefixes) 
> to an enterprise could be expected to insist that the enterprise 
> not be using any of those isolated addresses in their local 
> environment.

It is absolutely unreasonable for an ISP to tell their customer anything
about running their network that is not directely related to the
customer/provider interface. As long as the enterprise traffic over that
interface is related to the capabilities they are paying for, it is none
of the ISPs (or IETFs) business what they are doing elsewhere.

That said, I do have a draft that globally preallocates space in an
unabmiguous way
(http://www.ietf.org/internet-drafts/draft-hain-ipv6-pi-addr-03.txt).
This would allow use without the need to register, and if organizations
merged there would be no collision. As a side effect, when those values
were leaked into the global routing system, they can be proxy aggregated
at least at the transcontinental level. The text is currently focused at
the multi-homing problem, but it could easily be reworded.

> 
> I obviously don't understand all of the issues here well enough. 
> But the traffic of the last few days has left me with the strong 
> impression that SL may be an answer to the wrong question.  If 
> so, is the suggestion above closer to the right question?
> 
> And, unfortunately, since this approach involves a change in the 
> advice the IETF gives the RIRs, it probably does belong on the 
> IETF list and not that of a WG.

Eventually if policy needs to change, then yes. At this point though I
believe the fundamental issue is really about people coming to grips
with the concept that unlike IPv4, 

- all IPv6 nodes will have multiple addresses per interface. -

Once that is understood, the noise about the cost of renumbering goes
away because that is simply the act of adding a prefix to the nodes that
care to use it. If one chooses to take the old one away at some point,
that is fine. But that step is not mandatory, which significantly
reduces the costs associated with flash cutovers. This also means that
sites that want to filter can use different prefixes for global vs.
local access and only those nodes needing global access would configure
the global prefix. As you noted earlier, it really doesn't matter what
the local use prefix is for this purpose, the only reasons for the
ambiguous one is the lack of need to register it (pay and/or expose your
business case), the ability to keep those values out of the global
routing table, and for applications that care to look, a hint that there
is a filter somewhere in the network. 

Tony

---

From: "David R. Oran" <[email-masked]>
Date: Fri, 28 Mar 2003 14:00:31 -0500

Did anybody consider just handing out a /48 (or a bit smaller) 
automagically with each DNS registration?

--On Friday, March 28, 2003 10:36 AM -0800 Tony Hain <[email-masked]> 
wrote:

> _______________________________________________
> This message was passed through [email-masked], which
> is a sublist of [email-masked]. Not all messages are passed. Decisions on
> what to pass are made solely by Raffaele D'Albenzio.

------------------------
David R. Oran
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720
Office: +1 978 264 2048
VoIP: +1 408 571 4576
Email: [email-masked]

---

From: [email-masked]
Date: Fri, 28 Mar 2003 14:11:07 -0500

> automagically with each DNS registration?

Routing Table Bloat.  If you can figure out how to do this in a CIDR
aggregation context, or otherwise work around the table problem, the
IETF and NANOG will quite certainly jointly nominate you for sainthood. ;)

---

From: Keith Moore <[email-masked]>
Date: Fri, 28 Mar 2003 14:54:01 -0500

> IETF and NANOG will quite certainly jointly nominate you for

...right after you get lynched for heresy.

Keith

---

From: John C Klensin <[email-masked]>
Date: Fri, 28 Mar 2003 16:21:35 -0500

--On Friday, 28 March, 2003 14:54 -0500 Keith Moore 
<[email-masked]> wrote:

>> > Did anybody consider just handing out a /48 (or a bit
>> > smaller)  automagically with each DNS registration?
>>
>> Routing Table Bloat.  If you can figure out how to do this in
>> a CIDR aggregation context, or otherwise work around the
>> table problem, the IETF and NANOG will quite certainly
>> jointly nominate you for sainthood. ;)
>

yeah, well...

Tony is right -- any registration process costs resources.  But, 
if these addresses are assumed to be not routable, then there 
shouldn't be any routing table bloat.  Put differently, once can 
conceive of three ways to get addresses:

	* From an RIR, as PI space
	
	* From an ISP, as PD CIDR space.  ISPs might sensibly
	decide to charge less (in money or aggravation) for
	space which no one intended to route. Or might not: the
	marketplace is good at sorting out these things, as long
	as the RIRs are willing to make allocations to ISPs that
	reflect the desirability of having addresses for
	isolated networks unique and reflecting the ISPs to
	which they might ultimately connect.
	
	* From some other process, as long-prefix, almost
	certainly unroutable, isolated space.  This process
	could presumably be designed to be very lightweight in
	charges and administrative costs.

So, while I'm very hesitant about anything that ties addressing 
(of any sort) to DNS names, I'm not convinced that Dave's 
suggestion is worth dismissing out of hand.

Three additional observations:

(i) Tony's response to my note seems, to me, to turn SL largely 
into a policy problem, not a technical one.  We haven't have 
really good success binding policies into protocols.  That 
doesn't convince me that we should never do so, but it does seem 
to argue for looking at alternatives, even radical ones.

(ii) ISPs impose restrictions on their customers all the time 
and often even enforce them.  Many of us consider some of these 
to be desirable (e.g., terms and conditions prohibiting 
spamming) and others less so (e.g., prohibitions against running 
server or peer-peer protocols over a cable network or address 
restrictions that force reasonably-architected LANs into NAT 
arrangements) but the conditions clearly exist.

(iii) Yes, if I have an odd address and sufficient money, I can 
almost certainly convince some ISP to route it.  But that ISP's 
leverage to get its peers to accept any long-prefix addresses it 
happens to offer and route them may be distinctly limited, 
especially if, by offering/announcing those addresses, it is 
violating a well-understood policy against doing such things. 
(For example, an RIR policy that made PI address allocations 
much more difficult for ISPs who were guilty of routing table 
pollution by short prefixes could really focus the attention.) 
So it seems to me to be plausible to suggest that the right 
place to prevent routing table explosion (or even "bloat") is in 
routing decisions and acceptance of announcements, and not in 
creating special address scopes.

I also note that site local addresses open up a whole series of 
questions about "locality" and scope-range.  Perhaps we also 
need "ISP-local" addresses (routing into one ISP's space, or 
part of it, but not to that ISP's peers or transit customers) 
and so on.  The one thing that can be guaranteed about that sort 
of arrangement is an extension of the "pay enough and someone 
will route it" model will apply: If some ISP sees a potential 
competitive advantage in offering such a product (and 
addresses), the product will follow soon thereafter.  And, 
again, I think that this suggests that we had better figures out 
how to deal with these things on a policy basis, not a 
protocol-imbedded special address scope one.  We are almost 
certain to have the policy problem anyway and it is not clear 
that special cases for peculiar address scopes will buy us that 
much in addition.

       john

---

From: "Jeroen Massar" <[email-masked]>
Date: Fri, 28 Mar 2003 22:33:35 +0100

> automagically with each DNS registration?

I proposed a couple of times a /32 from which /48 can be requested
for 'private' (never to be connected to the internet) purposes.
I think some others have proposed a similar thing. But the opposers
think that it won't be 'free' then... but they will be unique :)

Greets,
 Jeroen

---

From: Bill Manning <[email-masked]>
Date: Fri, 28 Mar 2003 13:33:17 -0800 (PST)

John, mixed bag of nasties here.  Routing, addressing, and (of course)
 the DNS.  More fun than should be legal on a friday afternoon.

 Routing: there is a varient here. Think about routing table slots.
 If I get one, does it matter what the length of the prefix that I
 put in it?   There are other abstraction methods besides aggregation,
 at least thats what some smart people are telling me.

 The other bits will have to wait.

% 	* From an RIR, as PI space
% 	
% 	* From an ISP, as PD CIDR space.  ISPs might sensibly
% 	decide to charge less (in money or aggravation) for
% 	space which no one intended to route. Or might not: the
% 	marketplace is good at sorting out these things, as long
% 	as the RIRs are willing to make allocations to ISPs that
% 	reflect the desirability of having addresses for
% 	isolated networks unique and reflecting the ISPs to
% 	which they might ultimately connect.
% 	
% 	* From some other process, as long-prefix, almost
% 	certainly unroutable, isolated space.  This process
% 	could presumably be designed to be very lightweight in
% 	charges and administrative costs.
% 
% So, while I'm very hesitant about anything that ties addressing 
% (of any sort) to DNS names, I'm not convinced that Dave's 
% suggestion is worth dismissing out of hand.
% 
% Three additional observations:
% 
% (i) Tony's response to my note seems, to me, to turn SL largely 
% into a policy problem, not a technical one.  We haven't have 
% really good success binding policies into protocols.  That 
% doesn't convince me that we should never do so, but it does seem 
% to argue for looking at alternatives, even radical ones.
% 
% (ii) ISPs impose restrictions on their customers all the time 
% and often even enforce them.  Many of us consider some of these 
% to be desirable (e.g., terms and conditions prohibiting 
% spamming) and others less so (e.g., prohibitions against running 
% server or peer-peer protocols over a cable network or address 
% restrictions that force reasonably-architected LANs into NAT 
% arrangements) but the conditions clearly exist.
% 
% (iii) Yes, if I have an odd address and sufficient money, I can 
% almost certainly convince some ISP to route it.  But that ISP's 
% leverage to get its peers to accept any long-prefix addresses it 
% happens to offer and route them may be distinctly limited, 
% especially if, by offering/announcing those addresses, it is 
% violating a well-understood policy against doing such things. 
% (For example, an RIR policy that made PI address allocations 
% much more difficult for ISPs who were guilty of routing table 
% pollution by short prefixes could really focus the attention.) 
% So it seems to me to be plausible to suggest that the right 
% place to prevent routing table explosion (or even "bloat") is in 
% routing decisions and acceptance of announcements, and not in 
% creating special address scopes.
% 
% I also note that site local addresses open up a whole series of 
% questions about "locality" and scope-range.  Perhaps we also 
% need "ISP-local" addresses (routing into one ISP's space, or 
% part of it, but not to that ISP's peers or transit customers) 
% and so on.  The one thing that can be guaranteed about that sort 
% of arrangement is an extension of the "pay enough and someone 
% will route it" model will apply: If some ISP sees a potential 
% competitive advantage in offering such a product (and 
% addresses), the product will follow soon thereafter.  And, 
% again, I think that this suggests that we had better figures out 
% how to deal with these things on a policy basis, not a 
% protocol-imbedded special address scope one.  We are almost 
% certain to have the policy problem anyway and it is not clear 
% that special cases for peculiar address scopes will buy us that 
% much in addition.
% 
%        john
% 
% 

-- 
--bill

Opinions expressed may not even be mine by the time you read them, and
certainly don't reflect those of any other entity (legal or otherwise).

---

From: Keith Moore <[email-masked]>
Date: Fri, 28 Mar 2003 16:31:23 -0500

> Tony is right -- any registration process costs resources. 

agreed, though the cost of registering a domain name should serve as a useful
upper bound.  at least with address blocks you don't have to worry about I18N,
trademark infringement, etc.

> But,  if these addresses are assumed to be not routable, then there 
> 	* From an ISP, as PD CIDR space.  
>
> 	certainly unroutable, isolated space. 

actually it's highly desirable if such addresses *are* routable by private
agreement, just not by default.

I don't see why we shouldn't be able to choose from the above three options.

---

From: Bill Manning <[email-masked]>
Date: Fri, 28 Mar 2003 13:42:52 -0800 (PST)

% David R. Oran wrote:
% 
% > Did anybody consider just handing out a /48 (or a bit smaller) 
% > automagically with each DNS registration?
% 
% I proposed a couple of times a /32 from which /48 can be requested
% for 'private' (never to be connected to the internet) purposes.
% I think some others have proposed a similar thing. But the opposers
% think that it won't be 'free' then... but they will be unique :)

Been there, Done it, Bought everything.
SRInic was told to split the assignments into a "connected/unconnected"
database back in the day. It was ugly when folks figured that they
really wanted to be connected and passed muster. renumbering was less
fun in the late 1980s than today.
Never want to re-introduce this concept unless/until we can get to the
point of being able to painlessly renumber the entire Internet every
20 minutes.  Now where are those ""renumbering in IPv6 is easy" cookies.

--bill

---

From: "Jeroen Massar" <[email-masked]>
Date: Fri, 28 Mar 2003 23:46:38 +0100

Bill Manning [mailto:[email-masked]] wrote:

> 20 minutes.

That eliminates this 'solution'. History is bound to repeat
in these cases. Thus IMHO folks will just need to allocate
some random space or get it out some assigned space.

> Now where are those ""renumbering in IPv6 is easy" cookies.

Some other old stories made those crumble also :)
The renumbering isn't the part that is difficult, though it's
all the configuration items around it that's the burden.

Greets,
 Jeroen

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 28 Mar 2003 15:50:31 -0800

Note I said:
>>It is absolutely unreasonable for an ISP to tell their customer 
>>anything about running their network that is not directely 
>>related to the customer/provider interface. As long as the 
>>enterprise traffic over that interface is related to the 
>>capabilities they are paying for, it is none of the ISPs 
>>(or IETFs) business what they are doing elsewhere.

The ISPs do set terms for the customer/provider interface all the time,
and rightly so. They can not restrict me from setting up an 802.11 link
to my neighbor, only that my neighbor is not allowed to use that for
access to the provider's network. In a similar vein, the provider is not
in a position to tell customers what address space they can use for
purposes that do not interact with the provider interface. They can try,
and in a monopoly environment will probably succeed. That does not mean
we can tell ISPs to require that people not use any given address space
just because the provider is supplying another one. 

> that special cases for peculiar address scopes will buy us that 

Address filtering exists in the network today, and will continue. Since
that is done as an expression of local policies, you are correct the
whole discussion is really about policy. It is not clear to me what the
IETF is in a position to do, other than define the operation of a
multifacited DNS. ;)

Tony

---

From: John C Klensin <[email-masked]>
Date: Fri, 28 Mar 2003 20:22:37 -0500

--On Friday, 28 March, 2003 15:50 -0800 Tony Hain 
<[email-masked]> wrote:

>> and often even enforce them.  Many of us consider some of
>> these  to be desirable (e.g., terms and conditions
>> prohibiting  spamming) and others less so (e.g., prohibitions
>> against running  server or peer-peer protocols over a cable
>> network or address  restrictions that force
>> reasonably-architected LANs into NAT  arrangements) but the
>> conditions clearly exist.
>
> Note I said:
>>> It is absolutely unreasonable for an ISP to tell their
>>> customer  anything about running their network that is not
>>> directely  related to the customer/provider interface. As
>>> long as the  enterprise traffic over that interface is
>>> related to the  capabilities they are paying for, it is none
> The ISPs do set terms for the customer/provider interface all
> the time, and rightly so. They can not restrict me from
> setting up an 802.11 link to my neighbor, only that my
> neighbor is not allowed to use that for access to the
> provider's network. In a similar vein, the provider is not in
> a position to tell customers what address space they can use
> for purposes that do not interact with the provider interface.
> They can try, and in a monopoly environment will probably
> succeed. That does not mean we can tell ISPs to require that
> people not use any given address space just because the
> provider is supplying another one.

I'm interested in your "not in a position" comment.  Whether it 
is reasonable or not, ISPs include such restrictions in terms 
and conditions of service all of the time.  I have seen 
agreements that prohibit connecting more than one computer to an 
ISP-provided line, agreements that explicitly ban customer-side 
NAT boxes and restrict use to no more than one computer per 
ISP-provided address, and prohibit connecting their interfaces 
to anything resembling a LAN or to a machine that can gateway 
into a LAN.  I've also seen agreements that prohibit any use of 
tunnels into external mail servers or corporate LANs, presumably 
to get the customer to buy a higher-priced "commercial" service 
if anything other than home-type web browsing and associated 
email is to be done with the link.

Now some (or most) of these restrictions impress me, and 
probably you, as unreasonable.  We might choose to apply the 
"see if they can find out that I'm doing it" test to the 
restrictions and ignore them or, at the other extreme, apply the 
"don't sign anything on the assumption that the other party 
won't be able or inclined to enforce it" principle.

We, or more specifically, the upstream ISP or an RIR, can tell 
the ISP that things will go badly for them if they permit 
unroutable addresses to leak into the public Internet.  The only 
difference I can see between what I think is your SL address 
preference and my "unique, but unroutable" one  is that you 
would bind that advice/threat to a particular prefix while I 
would bind it to other indicators of "unroutable address".  The 
reserved prefix approach is less likely to get mucked up by a 
clueless ISP, but I am unconvinced that we should make special 
architectural provisions to make it easier to be in the ISP 
business while being clueless.

>> I also note that site local addresses open up a whole series
>> of  questions about "locality" and scope-range.  Perhaps we
>> also  need "ISP-local" addresses (routing into one ISP's
>> space, or  part of it, but not to that ISP's peers or transit
>> customers)  and so on.  The one thing that can be guaranteed
>> about that sort  of arrangement is an extension of the "pay
>> enough and someone  will route it" model will apply: If some
>> ISP sees a potential  competitive advantage in offering such
>> a product (and  addresses), the product will follow soon
>> thereafter.  And,  again, I think that this suggests that we
>> had better figures out  how to deal with these things on a
>> policy basis, not a  protocol-imbedded special address scope
>> one.  We are almost  certain to have the policy problem
>> anyway and it is not clear  that special cases for peculiar
>> address scopes will buy us that  much in addition.
>
> Address filtering exists in the network today, and will
> continue. Since that is done as an expression of local
> policies, you are correct the whole discussion is really about
> policy. It is not clear to me what the IETF is in a position
> to do, other than define the operation of a multifacited DNS.
> ;)

And, since I have seen split-horizon DNS implementations fail 
more often than not, I'm not sure I see a cure there either.

Regards,
     john

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 28 Mar 2003 18:01:30 -0800

John C Klensin wrote:
> ... but I am unconvinced that we should make special 

Isn't that just what we did with MPLS??  ;)
or does that just prove your point?  ;))

My arguments are more about acknowledging the reality and requirements
of the deployed architecture than they are about creating a special
case. Routing filters do and will exist, ergo local scope addresses will
exist. Applications will have to deal with that, yet there is no hint
unless we provide a well-known flag. I agree that applications should
not have to understand topology, but when they insist on passing around
topology information they have bought into the need to understand what
they are doing. DNS is one of the protocols that deals in topology
information, so it needs to understand topology. We need to make it
robust enough that applications can rely on it so they will simply pass
around names. 

In writing that it occurs to me that one of our failings is that we have
allowed a component of the system to have a very unrealistic (archaic)
view of what the network is. The DNS system is designed for the network
of 1985, and we blindly continue to use it as the database for locator
information in a very different network. I understand the IAB has
recently cleared its backlog of issues, so maybe this is a ripe topic
for them to address ...

Tony

---

From: John C Klensin <[email-masked]>
Date: Fri, 28 Mar 2003 11:10:56 -0500

Tony,

	

regards,
     john

---

From: Margaret Wasserman <[email-masked]>
Date: Mon, 31 Mar 2003 11:26:12 -0500

Hi John,

>But suppose we really do have enough address space (independent of routing 
>issues).  In that context, is site local just a shortcut to avoid dealing 
>with a more general problem?  Should we have a address allocation policy 
>that updates the policies of the 70s but ignores the intermediate "we are 
>running out" steps? Should I be able to go to an RIR and ask for unique 
>space for an isolated network, justify how much of it I need, and get it 
>-- with no promises that the addresses can be routed (and, presumably, 
>without pushing a wheelbarrow full of dollars/ euros/ yen/ won/ yuan/...)?

Yes, yes and yes.

Margaret

---

From: Keith Moore <[email-masked]>
Date: Mon, 31 Mar 2003 11:54:10 -0500

> case. 

Tony,

your arguments are an attempt to perpetuate costly mistakes that provide
little or no value.  you are not acknowledging reality, you are denying it.

> Routing filters do and will exist, ergo local scope addresses will
> exist. 

no.  it doesn't follow.  routing filters do and will exist, ergo there 
will always be some (source, destination) pairs that cannot exchange traffic
while those filters are in place.  this implies nothing about the scope of
those addresses.

> Applications will have to deal with that, yet there is no hint
> unless we provide a well-known flag.

applications cannot be expected to deal with filters in any way other than
to report that the communication is prohibited.  the "well known" flag
exists and is called ICMP.

site locals do not provide a well known flag because an application has
no idea about the site boundary, and when given an SL address has no idea
about which site that address belongs to.  if the app tries to use it from
the wrong site, it might even get sent to the wrong host (though this is
unlikely if stateless autoconfiguration is used).  still, rather than
getting an immediate ICMP prohibited the app gets a timeout, and the app
has no idea whether this is a temporary or permanent failure.  so SLs are
broken even from the standpoint of providing a well known flag.

> I agree that applications should
> they are doing. 

apps are not insisting on passing around topology information, because
mere addresses are not topology information.

> DNS is one of the protocols that deals in topology

false.  there's no way to make this work well.  you are trying to cripple the
v6 architecture so badly as to make it useless. 

> view of what the network is.

the archaic view is that scoped addresses are acceptable.  we've learned our
lesson with RFC 1918.  we know better now.  the original flat address space
design was superior.

---

From: Bill Manning <[email-masked]>
Date: Mon, 31 Mar 2003 09:01:43 -0800 (PST)

% >But suppose we really do have enough address space (independent of routing 
% >issues).  In that context, is site local just a shortcut to avoid dealing 
% >with a more general problem?  Should we have a address allocation policy 
% >that updates the policies of the 70s but ignores the intermediate "we are 
% >running out" steps? Should I be able to go to an RIR and ask for unique 
% >space for an isolated network, justify how much of it I need, and get it 
% >-- with no promises that the addresses can be routed (and, presumably, 
% >without pushing a wheelbarrow full of dollars/ euros/ yen/ won/ yuan/...)?
% 
% Yes, yes and yes.
% 
% Margaret

	Is may be worth noting that RIRs have -NEVER- made presumptions
	on routability of the delegations they make.

--bill

---

From: "Jeroen Massar" <[email-masked]>
Date: Mon, 31 Mar 2003 19:31:39 +0200

> 	on routability of the delegations they make.

Did you just say 69/8 ? :)

If an ISP chooses not to make a specific prefix reachable
it is there 'problem'/policy, not much to do about it.

Also anybody could just start up a Registry where one can
register IP addresses for their "Cybernet" or whatever
they call it. No need to go to the RIR's. The addresses
won't be accepted by the Internet community though ;)

Greets,
 Jeroen

---

From: John Stracke <[email-masked]>
Date: Mon, 31 Mar 2003 12:16:34 -0500

Keith Moore wrote:

>no idea about the site boundary,
>
Or boundaries: consider a private LAN where one part is firewalled from 
other parts of the same site.   The single flag "this address is 
site-local" cannot mark that boundary.

-- 
/============================================================\
|John Stracke      [email-masked]                     |
|Principal Engineer|http://www.centive.com                   |
|Centive           |My opinions are my own.                  |
|============================================================|
|"God does not play games with His loyal servants." "Whoo-ee,|
|where have you *been*?" --_Good Omens_                      |
\============================================================/