Subject: IPv6 will never fly: ARIN continues to kill it

From: Michael Richardson <[email-masked]>
Date: Wed, 12 Sep 2007 10:34:01 -0400

I have an application where I will have approximately 2000 hosts (many
of them virtualized) in a cabinet, and I will eventually have hundreds
of such cabinets spread around the world.  

Naturally, I want to directly address all such hosts, and it turns out
that IPv6 autoconfiguration is just perfect for these hosts.

I also control all the operating systems, and all my operating systems
are IPv6 capable (although my PXE systems will run over IPv4 until the
systems are booted).   I am willing to pay a registrar for some proper
IPv6 address space, specifically so that I can get the reverse map
properly delegated to me.  

This network will not likely to be announced in the default-free IPv6 zone.
(Of course, that's what Nortel, Apple, Ford, etc. said back when they got
their IPv4 /8's. Or rather, when Apple didn't..)

Site-local addresses could be used, but they are distasteful to me for
all the reasons that they were deprecated, and all the reasons in
rfc1627.
(ARIN has suggested that I might consider site-local addresses)

ARIN has asked told me:
     (2) In order to receive an initial IPv6 assignment, you must
	 qualify for an IPv4 assignment or allocation from ARIN under
	 the IPv4 policy currently in effect. 

Well, the answer would be, for this use would be "use 10.x" network for
IPv4.  That's why I asked for IPv6.
(none of the other rfc1918 spaces are big enough for my use, btw)

I am very disappointed. I don't expect anyone to go and fix ARIN.
I am simply posting to express myself.

I also have heard that RIPE isn't so non-sensical. 
It looks like I will use 6to4 to form my own /48.

- -- 
]            Bear: "Me, I'm just the shape of a bear."          |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] [email-masked]      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 12 Sep 2007 16:46:16 +0200

On Wed, Sep 12, 2007 at 10:34:01AM -0400,
 Michael Richardson <[email-masked]> wrote 

> (ARIN has suggested that I might consider site-local addresses)

Are you sure there was not a misunderstanding? As you say, site-local
addresses are deprecated but may be ARIN wanted you to use Unique
Local Addresses (RFC 4193), which *seems* a good solution for your
problem?

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 12 Sep 2007 11:35:13 -0400

If you have any chance that you will need to address those servers from the
public Internet, you should go for an allocation, in my opinion.

In RIPE NCC, with the existing policy, if you can show that those remote
sites are a kind of "internal ISP" for your organization(s), then you could
get an allocation.

Of course, you could use 6to4 and then setup your own relays, manually
configured instead of using the anycasted ones, but I think is much better
to use a regular allocation.

Regards,
Jordi

> De: Michael Richardson <[email-masked]>
> Responder a: <[email-masked]>
> Fecha: Wed, 12 Sep 2007 10:34:01 -0400
> Para: <[email-masked]>
> Asunto: IPv6 will never fly: ARIN continues to kill it
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
> Comment: Finger me for keys
> 
> iQEVAwUBRuf42ICLcPvd0N1lAQItGgf/dql1Yrs65S3+5OljPUaYnE4oJh+6FBAm
> TTD2Sq9xrhOUmT1fLMf4s0SicUEWtwGTMRWOUrrsExlr30I/OHKZGDwThqOYy/TI
> NQ3rNcCpFl8qGbL3C/Maqd9awuZLMq08IMwQSQua5mBGTe5t7YP3kmQQ2WvRAjBj
> 5VtjhH5pdpWaECbTuTl+5xyeyqVmthj9KU8C2/JEOSpm8Kj4pHQEdJ2PrBU7qDky
> p3MypwLHxGzg/m6fjKyE6S0bY0ENmx7Qii4w8tJDR1jNMeisb1Fx63Zxk6M/FJRF
> ZMdcjyt0dtIIiZCLC4K4sAd14zn/m17yZtg7JVFl+Rg+a9Bhnwxcww==
> =Ktao
> -----END PGP SIGNATURE-----
> 

**********************************************
The IPv6 Portal: http://www.ipv6tf.org

Bye 6Bone. Hi, IPv6 !
http://www.ipv6day.org

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

---

From: [email-masked]
Date: Wed, 12 Sep 2007 17:07:04 +0000

> I am simply posting to express myself.

nevertheless i hope that you will help fix ARIN if it's broken.  but
in this case i think what's broken is bigger than ARIN.  the community
badly needs a way to allocate addresses, which as in your example, are
unlikely to appear in the global routing table (sometimes called "DFZ").
these addresses should have whois, in-addr, and so on, so that they can
be used in "ubiquitous manet"'s and ad-hoc wireless.  given that the
internet core can't handle growth of PI, and no large internet entity
in their right mind would use PA, it is past time to end what i call
"the tyrrany of the core".

http://sa.vix.com/~vixie/ula-global.txt has my thoughts on this, which
i've appropriated without permission from hinden, huston, and narten
and inaccurately failed to remove their names from (since none of them
supports the proposal).  in fact, nobody in the ietf intelligensia
supports the proposal.  the showstopped is that this appears to many as
an end-run around PI, and the fear is that there's no way to prevent it
from all getting routed anyway.  while that's not an unreasonable fear,
i'm alone in considering it a manageable risk.  there's also a problem
in that the only way to get new address policy through to the RIRs is
now the global RIR policy process -- it's not a matter of IAB telling
IANA what to do like in the old days.

so while i harken to your concern that "IPv6 will never fly", i think
that the reasons for it are much larger than whatever part you think
ARIN could do differently.  but as to that part, please listen to sam
weiler who spoke the truth as i know it when he said:

	It is remarkably easy to get involved with the ARIN public policy
	procecss and submit a proposal to change its v6 assignment policies. I
	encourage you to do so.

	-- Sam

paul

---

From: Michael Richardson <[email-masked]>
Date: Wed, 12 Sep 2007 13:13:17 -0400

>>>>> "Stephane" == Stephane Bortzmeyer <[email-masked]> writes:

    Stephane> Are you sure there was not a misunderstanding? As you say,
    Stephane> site-local addresses are deprecated but may be ARIN wanted
    Stephane> you to use Unique Local Addresses (RFC 4193), which
    Stephane> *seems* a good solution for your problem?

  That may be the case. 
  I will ask them.

  I was not aware of Unique Local Addresses, RFC4193. I will consider
them.  Getting the reverse names configured correctly everywhere is a
pain, since I had to make sure that I've gotten all the recursive name
servers configured as secondaries for the prefix that I choose, but a
reverse name lookup failure is not the end of the world.

- --

---

From: "Roger Jørgensen" <[email-masked]>
Date: Wed, 12 Sep 2007 20:07:23 +0200

On 9/12/07, [email-masked] <[email-masked]> wrote:
<snip>
> an end-run around PI, and the fear is that there's no way to prevent it

are they still refusing to put it into the queue or do anything? Even after
several month? Well let really hope that will change now when/if
IPv6-wg change the name to 6man and we can start working again!

<snip>
-- 

Roger Jorgensen           |
[email-masked]          | - IPv6 is The Key!
http://www.jorgensen.no   | [email-masked]

---

From: Paul Vixie <[email-masked]>
Date: Wed, 12 Sep 2007 18:17:16 +0000

> > http://sa.vix.com/~vixie/ula-global.txt has my thoughts ...
> 
> are they still refusing to put it into the queue or do anything?

"refuse" is such a strong word.

> Even after several month? Well let really hope that will change now when/if

i'm happy to be part of an effort, but i'm done with the OMAC approach in IETF.

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Thu, 13 Sep 2007 09:13:56 +0900 (JST)

> of such cabinets spread around the world.  
(snip)

	i wonder - why do you require it be a continuous address space?
	if your device do authenticate properly with each other, you can just
	use IPv6 prefixes from local ISPs (PAs).

itojun

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Thu, 13 Sep 2007 09:15:12 +0900 (JST)

> > an end-run around PI, and the fear is that there's no way to prevent it

	because, in the end, ULA (whichever flavor it is) leads to IPv6-to-IPv6
	NAT.

itojun

---

From: Mark Andrews <[email-masked]>
Date: Thu, 13 Sep 2007 10:53:58 +1000

> 	because, in the end, ULA (whichever flavor it is) leads to IPv6-to-IPv6

	Only if you think in IPv4 terms.

	Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: David Conrad <[email-masked]>
Date: Wed, 12 Sep 2007 19:45:13 -0700

> 	Only if you think in IPv4 terms.

And telcos, cable companies, and my grandmother often think in IPv6  
terms.

Itojun is most likely right. Most people (and large corporations)  
tend to go with what they're familiar with.

Regards,
-drc

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Thu, 13 Sep 2007 15:13:12 +0900 (JST)

> > 	because, in the end, ULA (whichever flavor it is) leads to
> >       IPv6-to-IPv6 NAT.
> 
> I prefer losing some bytes in all my packets between locations using
> different ULA-D prefixes to get an underlying VPN / tunneling
> infrastructure. This allows me to keep things flat, i.e. pure routing.
> 
> itojun, let's just stop using the 3 letters word. It does not exist
> anymore.

	is it ULA, NAT, VPN or all of them :-)

itojun

---

From: "Michel Py" <[email-masked]>
Date: Wed, 12 Sep 2007 23:43:58 -0700

> Paul Vixie wrote:
> i'm alone in considering it a manageable risk.

I'm afraid I'll have to leave you alone there. [RIR-PI] makes [ULA-GLOBAL-00] somehow palatable, but not enough. In a nutshell, your argument is that since [RIR-PI] has been adopted, there is little risk that [ULA-GLOBAL-00] degenerates into free-for-all PI.

That's a valid point, but IMHO the problem is that [RIR-PI] is not good enough in too many eyes; in other words there still are many remaining temptations to abuse [ULA-GLOBAL-00].

> so while i harken to your concern that "IPv6 will never fly",
> i think that the reasons for it are much larger than whatever
> part you think ARIN could do differently.

Agree.

>> Michel Py wrote:
>> The real world would probably go for IPv6 NAT instead, but
>> the IETF is deadlocked; instead of choosing between the
>> lesser of two evils and sacrifice one of the "features",
>> they want to have the cake and eat it too.

> Paul Vixie wrote:
> ietf said don't do nat in v4.  the market said screw you. The
> market won, and ietf ended up having to add nat support into
> various protocols, and started having nat oriented working
> groups, and so on. i expect the same with nat v6.

I agree, but my point was that the market might prefer double-v4NAT to IPv6 NAT. The situation is quite different: IPv4 NAT solved most of the renumbering issue. IPv6 NAT does not bring anything to the table that IPv4 NAT does not already have. In other words: if you want NAT, no point upgrading to IPv6.

> i have more confidence in the ability of router vendors to bend moore's
> law and in backbone architects and routing protocol architects to bend
> graph theory, than i have for example in diesel-from-algae as a way to
> solve the world's carbon problem.  so i'm not nec'ily hopeful, but i'm
> more hopeless about other things than i am about a 2M-route DFZ.

Agree too, but as you said above the reasons are much larger. In other words, even if vendors promised a 10M DFZ capable routers and the RIRs gave PI to anybody who asks for it, we would still be nowhere near take off.

> Roger Jørgensen wrote:
> are they still refusing to put it into the queue or do anything? Even
> after several month? Well let really hope that will change now when/if

A few months are very little time in IETF time!

Michel.

---

From: "Roger Jørgensen" <[email-masked]>
Date: Thu, 13 Sep 2007 08:51:58 +0200

>         because, in the end, ULA (whichever flavor it is) leads to IPv6-to-IPv6

did you read the thread some months ago? There was mention ID and LOC splitting.
ULA fits that idea almost perfect.

-- 

Roger Jorgensen           |

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Thu, 13 Sep 2007 15:56:26 +0900 (JST)

> did you read the thread some months ago? There was mention ID and LOC
> splitting.  ULA fits that idea almost perfect.

	IP address, or part of it, can never be an ID.  so i'm against of
	all of the ID/LOC separation stuff.

	IP address can never be an identifier because:
	- you can switch from one IP version to another
	- once you have private address/ULA of some sort, you have conflicts

	it is a crazy thought that you have a unique ID in the lower 64 bit in
	an IPv6 address.  MAC address is indeed not unique - some vendors do
	not keep the rules.  go down to hongkong/akihabara and buy cheap NE2000
	ethernet cards, and you'll know.

	if you need to identify some node/whatever, use ssh secret key, X509
	certs, and alike.  IP address is just to specify communication endpoint,
	nothing else.

itojun

---

From: "Michel Py" <[email-masked]>
Date: Thu, 13 Sep 2007 00:00:33 -0700

> Roger Jørgensen wrote:
> did you read the thread some months ago? There was mention
> ID and LOC splitting. ULA fits that idea almost perfect.

ID/LOC has been discussed for 11 years and canned several times.
http://arneill-py.sacramento.ca.us/ipv6mh/draft-odell-8+8-00.txt

---

From: Jari Arkko <[email-masked]>
Date: Thu, 13 Sep 2007 11:24:49 +0300

Michael,

Here's a decision table for you:

1. Do you need addresses that are routable from the global
    Internet, from anywhere?

    (Its not clear to me that you do, because you only need to
    do that within your own network and a couple of well
    known external sites perhaps.)

    a. If not, maybe you should look at ULAs. RFC 4193 allows
        you to get these addresses randomly, and you do not
        need to ask permission from anyone to do it. You could
        have your addresses today if you wanted to.

    b. Proposals have been floated about non-random ULAs
        as well. Right now we do not have one, but I'm not
        sure you need this for your particular case.

2. If you do need addresses that are routable, is it
    sufficient for you to work with provider-aggregated
    addresses that you get from your ISP (not from ARIN)?

    If yes, get the addresses and use them!

3. If you do need addresses that are routable AND
    you have multiple ISP connections and want to stay
    away from an address renumbering if you need
    to change ISPs, then you need PI. You are starting
    to get PI space, but as numerous PI items in the
    global routing table cause pain for routers, this
    will likely be available only for larger enterprises.

    There is ongoing work to try to design a better
    routing system that would be capable of keeping
    tens of millions of prefixes or more, in the IRTF.
    If and when that work succeeds, it would be possible
    to allocate everyone their own PI prefix. We are
    not there yet.

In any case, FWIW, I think it would make sense for RIR
address allocation rules to allow IPv6-only operations
and not just those that need both IPv4 and IPv6 address
space.

Jari

---

From: Jari Arkko <[email-masked]>
Date: Thu, 13 Sep 2007 13:16:36 +0300

Roger,

> IPv6-wg change the name to 6man and we can start working again!

For the record, we had a series of discussions among authors, Paul,
experts, etc on the ULA topic right after IETF-69 to try to see if we
can sort out what the problems are and move forward.

For background, we already have ULAs than can be allocated by
the sites themselves. These are defined in RFC 4193.

The question on the table (and also part of 6man charter)
is whether we need an additional type of ULAs, one that is
centrally allocated. Such addresses might be useful for a couple
of reasons. One reason is that we could guarantee uniqueness,
which might be important, e.g., for a company that is running
a lot of small company networks as a business, and wants to
ensure the address spaces do not collide. But another, more
important stated reason was that we should have a way give
people address space that is different from PI in the sense
that those addresses are not recommended to be placed
in the global routing table.

Arguments against such address space relate to the
following issues:

- The costs for any centrally allocated  space are likely going to
  be the same, so what is the incentive for the customers to
  allocate ULA-C instead of PI?

- There is no routing economy that would push back on
  advertising more than the necessary prefixes, so
  what is the incentive that keeps the ULA-C out
  of the global routing table as years go by? (When
  the companies that allocated ULA-C grow, merge,
  need to talk with other companies, etc.)

The end result of our discussions was that we clearly do not
have agreement on the  way forward, and we settled for
writing a draft about the issues instead. That is still in the
works.

Jari

---

From: [email-masked] (Arnaud Ebalard)
Date: Thu, 13 Sep 2007 08:10:27 +0200

Hello,

Cheers,

a+

---

From: [email-masked] (Arnaud Ebalard)
Date: Thu, 13 Sep 2007 08:23:35 +0200

Oy,

> 	is it ULA, NAT, VPN or all of them :-)

Good point. The answer is in my mail address ;-)

a+

-- 
Arnaud Ebalard  
EADS Innovation Works - IW/SE/CS - IT Sec Research Engineer
PGP KeyID:047A5026 FingerPrint:47EB85FEB99AAB85FD0946F30255957C047A5026
_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 13 Sep 2007 14:26:47 +0200

> from all getting routed anyway.

You have my support for the most part, for whatever that's worth.

The only part I disagree with is the involvement from the RIRs: those  
cater to ISPs 99% of the time and are as such in a bad position to  
sell addresses that aren't related to internet service provision.  
Selling these prefixes fits much better with the way domain  
registrars operate.

---

From: Marshall Eubanks <[email-masked]>
Date: Thu, 13 Sep 2007 08:56:41 -0400

Dear Jari;

>     will likely be available only for larger enterprises.

I do not really agree with this. First, the routing tables do not  
care if you have PI or PA space, just whether
it is announced or not. If you are already announcing PA space, and  
getting into the DFZ, it does not harm the tables if you change to PI  
space. Second, one of reasons I helped to write and push through ARIN  
2002-3 (micro assignments) was that I felt that small multi-homers  
(i.e., enterprises that were multi-homed but did not need large  
address allocations) did not constitute a threat to the routing  
tables, and that has been borne out by experience. Neither the growth  
nor the bloat in the routing tables is being driven by small multi- 
homers. This has been discussed at great length on ARIN PPML and  
other lists.

Yes, I gave numbers to Vince Fuller about millions of multi-homers,  
but that was to set an upper bound on the process. I do no believe  
that every small business will rush out and multi-home, no matter how  
automated BGP becomes. The small businesses that I know that multi- 
home (mostly high traffic volume companies providing network  
services, such as video streaming) have a business need to do so, and  
it is not realistic nor in my opinion proper to assume that they will  
not be able to do so, one way or the other.

> and not just those that need both IPv4 and IPv6 address

I fully agree here. In fact, I would say that IPv6 will have truly  
succeeded when business requests start coming in
that do _not_ want IPv4 space. This should be encouraged, not  
discouraged.

> Jari

Regards
Marshall

---

From: Jari Arkko <[email-masked]>
Date: Thu, 13 Sep 2007 16:04:38 +0300

Marshall,

> I do not really agree with this. First, the routing tables do not care
> if you have PI or PA space, just whether

Sure. But I understood Michael has nothing now, so from his
point of view its a question of getting either PI from ARIN or
PA from his provider.

> Second, one of reasons I helped to write and push through ARIN 2002-3
> (micro assignments) was that I felt that small multi-homers (i.e.,
> enterprises that were multi-homed but did not need large address
> allocations) did not constitute a threat to the routing tables, and
> that has been borne out by experience. Neither the growth nor the
> bloat in the routing tables is being driven by small multi-homers.
> This has been discussed at great length on ARIN PPML and other lists.
>
> automated BGP becomes. The small businesses that I know that
> multi-home (mostly high traffic volume companies providing network

Ok, I stand corrected. I did not realize this option was
available to the smaller entities. (But is that for IPv4,
or does it apply to IPv6, too?)

> that do _not_ want IPv4 space. This should be encouraged, not

Yep.

Jari

---

From: Marshall Eubanks <[email-masked]>
Date: Thu, 13 Sep 2007 09:50:04 -0400

> or does it apply to IPv6, too?)

That was 2005-1, which was also adopted. It's not quite the same, but  
close.

Regards
Marshall

---

From: Michael Richardson <[email-masked]>
Date: Thu, 13 Sep 2007 10:27:00 -0400

> point of view its a question of getting either PI from ARIN or

   No, it's PI from ARIN, or PA from *some* provider.

   My immediate need is for space which is unique, and has whois and reverse 
map. I don't need it to be routeable today.  But, sh*t happens, and we notice 
that eventually, everything needs some reachability to places you didn't 
expect. I expect to need tunnels in some places to get routeable IPv6 into 
places where there is none.  I can get address space from existing IPv6 
tunnel brokers, but in the long term, this may be unsustainable, since I 
expect to push some significant traffic.

   In any case, I expect to put equipment in places where there is presently 
no IPv6, so a tunnel will become necessary anyway.  A /48 is pretty damn big, 
but if I have to get another /48 (in PA space), and break aggregation to 
announce it wherever I can, I may do that.  I could also use many /64s in
data centres that are IPv6 ready, however, this may complicate things.
   The tunnels between data centres *may* be layer-2 tunnels to permit the 
(virtual) hosts to migrate. There are scaling issues with this, and MIPv6 
might be a better solution. This is more than a year away.

   I have presently acquired enough address space from another place to 
permit me to continue work. I thought that asking ARIN first made more sense.

marshall> I fully agree here. In fact, I would say that IPv6 will have truly
marshall> succeeded when business reqFrom [email-masked] Fri Sep 14 08:47:43 2007
To: [email-masked]
From: Michael Richardson <[email-masked]>
Date: Thu, 13 Sep 2007 10:27:00 -0400
Lines: 36
Subject: Re: IPv6 will never fly: ARIN continues to kill it

> point of view its a question of getting either PI from ARIN or

   No, it's PI from ARIN, or PA from *some* provider.

   My immediate need is for space which is unique, and has whois and reverse 
map. I don't need it to be routeable today.  But, sh*t happens, and we notice 
that eventually, everything needs some reachability to places you didn't 
expect. I expect to need tunnels in some places to get routeable IPv6 into 
places where there is none.  I can get address space from existing IPv6 
tunnel brokers, but in the long term, this may be unsustainable, since I 
expect to push some significant traffic.

   In any case, I expect to put equipment in places where there is presently 
no IPv6, so a tunnel will become necessary anyway.  A /48 is pretty damn big, 
but if I have to get another /48 (in PA space), and break aggregation to 
announce it wherever I can, I may do that.  I could also use many /64s in
data centres that are IPv6 ready, however, this may complicate things.
   The tunnels between data centres *may* be layer-2 tunnels to permit the 
(virtual) hosts to migrate. There are scaling issues with this, and MIPv6 
might be a better solution. This is more than a year away.

   I have presently acquired enough address space from another place to 
permit me to continue work. I thought that asking ARIN first made more sense.

marshall> I fully agree here. In fact, I would say that IPv6 will have truly
marshall> succeeded when business requests start coming in
marshall> that do _not_ want IPv4 space. This should be encouraged, not
marshall> discouraged.

   I'm here. I'm bit more clueful about ARIN process than average.
   Most businesses would have no idea what to do once ARIN said no.
   Or, they'd just lie.

---

From: Lixia Zhang <[email-masked]>
Date: Sun, 16 Sep 2007 19:04:23 -0700

On Sep 13, 2007, at 3:16 AM, Jari Arkko wrote:

> .......

I'm just catching up with this thread today: If I summarize my  
understanding from the above in one sentence: there seems a perceived  
difference between PI and ULA-C prefixes, which, as far as I can see,  
does not exist.

Whether a unique prefix is/not globally routable is determined by  
whether it gets injected into the routing system, no matter how it is  
labeled.

Lixia

---

From: Jari Arkko <[email-masked]>
Date: Mon, 17 Sep 2007 07:12:48 +0300

Lixia,

> whether it gets injected into the routing system, no matter how it is

Right. Or we can try to label it, but that labeling
may not correspond to what is actually done with
it.

Jari

---

From: "Tony Hain" <[email-masked]>
Date: Tue, 18 Sep 2007 08:09:24 -0700

> may not correspond to what is actually done with

If you don't label it there is no clearly agreed way to filter these out if
you don't want them. 

The people that are fighting having ULA-C are the same ones that don't want
PI, and they are trying to force ULA-C == PI so they can turn that argument
around and say 'we told you PI was a bad idea' when there is no way to
filter out what would have been ULA-C. If you really believe there is going
to be a routing system problem, then you absolutely have to support ULA-C
because it is the only way to enforce keeping private space private.

Tony

---

From: Jeroen Massar <[email-masked]>
Date: Tue, 18 Sep 2007 16:50:24 +0100

Tony Hain wrote:
[..]
> because it is the only way to enforce keeping private space private.

I don't think ULA-C makes sense. We have a RIR system in place. These
RIRs are supposed to provide address space for people/organizations who
can justify a need for that address space. Clearly everybody does want
this address space to be unique and a lot of people for various reasons
(statistics, contact info, who it belongs to, which country, etc) want
to have at least an entry somewhere in a database that is publicly
available.

As at least ARIN, APNIC and AfriNIC have policies in place now, which
break the "global policy" that once existed, to provide /48's and upward
to individual sites. These sites might or might not be (completely)
connected to the Internet, there is no requirement anywhere to do so.

As such, there is already a perfect method of getting globally unique
and registered address space. As such, there is no need for ULA-C.

Which is good, as any address space that gets marked as 'special' will
be unusable because some people won't ever update filters, which is
their problem of course, but it will hurt others.

As history has shown that one day or another you will want to connect to
the Internet, having those blocks simply come from the RIRs is the
perfect way to do it.

As for the routing system problem, simple Economics will resolve that.
Either Transit Providers will stop accepting certain sized prefixes or
they will nicely start charging serious amounts of cash for the routing
slots they occupy.

In the mean time the great people working on the ram@iab list will find
a great method of avoiding that problem. We are at <900 prefixes in IPv6
and I really don't see it hitting 100k of them any time soon. When it
does, then we know that we might need to hurry up a bit. But as the IPv4
tables are already at 230k and are doing fine, I think we can have quite
a couple of quiet years before that will become a serious issue,
especially when ISPs can always filter if they want.

Checking the Looking Glass of GRH (http://www.sixxs.net/tools/grh/) it
shows also that quite some ISP's are already attempting de-aggregation
of their /32's and even the /20's they have received. Still the basic
premise is that they should only be announcing that single prefix and
most likely they only connect to you at one/two common points anyway and
you won't need their more specifics. As such you can filter on those
borders to avoid those few routes.

Greets,
 Jeroen

---

From: Ted Hardie <[email-masked]>
Date: Tue, 18 Sep 2007 09:10:50 -0700

>because it is the only way to enforce keeping private space private.

I am totally against ULA-C, and I am not against PI, so please re-examine
that statement.  Your second statement:

>f you really believe there is going

Also doesn't seem to me to make a lot of sense.  There is a set prefix of
ULAs now.  Filtering it on is already possible (and I heartily encourage
same!).  Adding ULA-C doesn't make that easier or harder, and it does nothing
else that would "enforce keeping private space private".  None of the
ULA-C proposals I have seen came with a police force or standing army
of clue-bat wielding networking engineers.

				Ted

---

From: Lixia Zhang <[email-masked]>
Date: Tue, 18 Sep 2007 10:31:45 -0700

> If you don't label it there is no clearly agreed way to filter  

I'd agree that, ideally speaking, one would prefer using simple  
filtering rules.

However as Jari already pointed out, whatever label one puts on a  
prefix may not correspond to what is done with it, *especially* as  
time goes.
(a motto I heard from my high school son, "the only thing that does  
change in life is change" :-)

and I would not attempt to bundle opinions regarding UCL-C and PI (I  
saw Ted already showed an example).  Furthermore, we are all in this  
continuing process of understanding their implications in this  
complex, exciting, and constantly changing Internet.

---

From: Lixia Zhang <[email-masked]>
Date: Tue, 18 Sep 2007 10:31:45 -0700

---

From: Paul Vixie <[email-masked]>
Date: Tue, 18 Sep 2007 17:52:27 +0000

> >if you really believe there is going to be a routing system problem, then
> >you absolutely have to support ULA-C because it is the only way to enforce
> >keeping private space private.
> 
> same!).  Adding ULA-C doesn't make that easier or harder, and it does
> nothing else that would "enforce keeping private space private".  None of
> the ULA-C proposals I have seen came with a police force or standing army of
> clue-bat wielding networking engineers.

the concern i heard wrt ULA-G (and therefore wrt ULA-C upon with -G is based)
is that the filtering recommendations in RFC 4193 were as unlikely to "work"
as the filtering recommendations in RFC 1597 and RFC 1918.  and that with a
global registry of whois and in-addr, ULA-G (and therefore ULA-C) prefixes and
packets would have considerably greater utility when leaked than RFC 1597/1918
prefixes and packets.  so with demonstrable ease of leakage and demonstrably
higher utility of leakage, nobody anywhere believes that ULA-G (and ULA-G)
won't be leaked.  on that basis, ULA-G (and ULA-C) are said to be functional
equivilents to PI space.

i don't like or agree with this reasoning.  i'm just saying what i've heard.

someone on ARIN PPML accused ULA-C (and therefore ULA-G) of being an "end run
around PA/PI" by which they meant "a way to get the benefits of PI without
qualifying for the costs imposed by PI on everyone else in the DFZ".  i
realized in that moment, that ULA-G (and therefore ULA-C) is not an end run
around PI space, it's an end run around the DFZ.  some day, the people who are
then responsible for global address policy and global internet operations,
will end the "tyranny of the core" by which we cripple all network owners in
their available choices of address space, based solely on the tempermental
fragility of the internet's core routing system.  but we appear not to be the
generation who will make that leap.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 18 Sep 2007 19:57:32 +0200

On 18-sep-2007, at 17:50, Jeroen Massar wrote:

> can justify a need for that address space.

That's like selling train tickets at the airport. Except for the  
fraction of a promille of all IP users that have their own portable  
address space, RIRs don't even talk to IP users who are _connected_  
to the internet, let alone those who aren't! It just doesn't make  
sense to involve the RIRs here.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 18 Sep 2007 19:59:16 +0200

On 18-sep-2007, at 18:10, Ted Hardie wrote:

>> filter out what would have been ULA-C.

> that statement.

I'm in favor of ULA-C and against the current IPv6 PI policies, so it  
seems the statement indeed doesn't universally apply...

---

From: Jeroen Massar <[email-masked]>
Date: Tue, 18 Sep 2007 19:04:56 +0100

Iljitsch van Beijnum wrote:
> address space, RIRs don't even talk to IP users who are _connected_ to
> the internet, let alone those who aren't! It just doesn't make sense to
> involve the RIRs here.

Then setup an LIR who gets a /32 from the RIR and let that RIR handle
all enduser conversions about this. That covers 65k /48's and thus
endsites, when they run out of space, well they have their whois, they
have their DNS delegations recorded, thus they can easily justify more
address space.

You can make that LIR a non-profit organization where every member pays
their share of the LIR fees that the organization has to pay yearly to
the RIR. Presto problem solved.

This is already what is in place today, you just need a friendly LIR.

But for some reason people don't want this, as the LIR can go belly up?
Odd eh.

Greets,
 Jeroen

---

From: Keith Moore <[email-masked]>
Date: Tue, 18 Sep 2007 18:10:22 -0400

Paul Vixie wrote:
> i realized in that moment, that ULA-G (and therefore ULA-C) is not an
> end run around PI space, it's an end run around the DFZ. some day, the
> people who are then responsible for global address policy and global
> internet operations, will end the "tyranny of the core" by which we
> cripple all network owners in their available choices of address
> space, based solely on the tempermental fragility of the internet's
> core routing system. but we appear not to be the generation who will
> make that leap.
Mumble.  It's hard for me to buy the idea of there not being a "core"
portion of the Internet from which all public addresses are reachable. 
But I can imagine a world in which there are industry-specific cores,
"mini-cores" if you will, that aren't part of the public Internet (in
that they are not reachable in general from networks that aren't
connected to that mini-core) but which provide reachability between
parties within a particular industry.  For instance, I could imagine the
banking industry having a mini-core that facilitated transactions
between banks, and there being another mini-core to facilitate
transactions between automobile manufacturers and their parts suppliers,
and another mini-core that served to connect retail chains with their
product suppliers.  A business could connect to multiple mini-cores. 
And part of the purpose of these mini-cores would be to let businesses
with mutual interest in connecting, connect without having to arrange
bilateral private interconnection, and still have their b2b machines
isolated from the public network.

All of those mini-cores could, in principle, exchange advertisements of
reachability to ULA prefixes, or for that matter other kinds of prefixes. 

Most of the businesses that had presence on those mini-core networks
would also have presence on the public Internet for public web access,
email, etc., and they would need public prefixes for that.   And it
might even be the case that those applications that offered services to
the public would be tolerant of renumbering.

What bugs me is that I think that the existence of mini-cores (or more
generally, a large number of private interconnections between networks
using ULA prefixes) leads to a world where it becomes important to have
a particular kind of source address to talk to a particular kind of
destination address, and in which applications are expected to choose
the right source address in order to talk to a particular kind of
destination address.  So the sources addresses available to a particular
host end up being like a keyring.  I don't think that's a good burden to
put on apps, and I don't think that using addresses like authentication
tokens is a good way to go.

Keith

---

From: Paul Vixie <[email-masked]>
Date: Wed, 19 Sep 2007 00:50:44 +0000

> portion of the Internet from which all public addresses are reachable. 

i was going to say, "but these addresses aren't public", but then i saw the
larger problem, which is that the internet's architecture has guardians who
are able to either buy into, or not, various ideas.  sometimes this is a
good thing, as with the wildcard *.COM that pointed to a sitefinder service.
other times this isn't a good thing, as occurred with NAT, firewalls, and
application layer gateways.  how to tell good from bad?  i think it's 
whether the guardians think the idea is a stupid waste of the proposer's
time, or whether they think it will do outright harm.

"harm" becomes the important term in that equation... is it harmful to let
someone else's idea go forward because it will dilute the need for a better
solution?  that's why a lot of people think DNSSEC DLV is bad -- simply that
it would take pressure off signing the root zone.  is it harmful to set up
a service that stops RCODE=3 responses from coming back when a nonexistent
name ending in ".COM" is looked up?  that's what i said when verisign added
a *.COM wildcard pointing to sitefinder.

without a consensus on what it means "to harm", we're sort of stuck.  ULA-G
(and therefore ULA-C) would allow consenting adults to exchange routes using
the whois and in-addr infrastructure that has historically been reserved for
"public networking".  lots of people, fearing leakage of "local" to "public",
think there is too much latent harm in this kind of centralized locality.  in
the IETF, the naysayers pretty much kick the consenting adults' asses every
day and twice on sunday.  and that's the real problem here, i finally think.

---

From: Keith Moore <[email-masked]>
Date: Tue, 18 Sep 2007 21:49:35 -0400

Paul Vixie wrote:
> are able to either buy into, or not, various ideas. 
"guardians" seems a bit skewed. within IETF, the RIRs, ICANN, USDoC,
Verisign,  Cisco, or Microsoft it might make sense to think of there
being guardians who can promote a bad technology or block a good one,
each within their particular sphere.  but I find it hard to think of the
LAN manager who buys a NAT box as being a guardian.  sure the vendors
hawked them and misrepresented them, but the consumers kept buying them,
because there wasn't a better way to get that functionality in IPv4. 
>  sometimes this is a
it certainly is a problem.  and yet failure to provide direction seems
to cause even more problems.

Keith

---

From: Paul Vixie <[email-masked]>
Date: Wed, 19 Sep 2007 02:03:20 +0000

> to cause even more problems.

providing leadership is different from providing direction.  it includes
things like unsolicited positive vision and innovation, and willingness toward
constructive criticism and guidance when solicited.  it does not include
crapping all over ideas that merely sound dangerous, where the dangers are
latent, and where the harm if any would be that time is wasted.

providing direction is more like preventing consenting adults from doing stuff
that you would find distasteful, and it's paternalism or nannyism, and no good
has come of it in the internet field.

---

From: Keith Moore <[email-masked]>
Date: Tue, 18 Sep 2007 22:49:44 -0400

> latent, and where the harm if any would be that time is wasted.
There are lots of hazards.  One of those that bugs me most is when a
mediocre idea that might become a good idea with a bit of refinement,
gets "crapped on" and dies a premature death, and then can't be
resurrected for a decade or so because nobody wants to take the
political risk.

(Another one that bugs me almost as much is when a potentially good idea
or insight gets killed because of some tangential discussion that
diverts attention away from the potentially good idea or insight.)
> has come of it in the internet field.
We probably disagree about the last part.  Or maybe it's just imprecise
wording on my part.   I mostly view the IETF's job as providing
consenting adults with good ways to do the things that they want or need
to do.  If we fail to provide good ways, consenting adults might (and
usually do) come up with worse ways.   It's not that consenting adults
shouldn't be able to solve their own problems, it's that some kinds of
solutions can and do cause harm for the Internet, particularly when
they're widely deployed.   If we can come up with better ones that are
attractive enough to consenting adults, it seems like that would be
doing good....presuming that having a robust and flexible Internet
really is a good thing.

Keith

p.s. And FWIW, in the message where I said 'It's hard for me to buy the
idea of there not being a "core" portion of the Internet from which all
public addresses are reachable' what I meant was that I have a hard time
imagining the conditions which would make it happen, not that I would
try to stop it from happening.   I'd be hard pressed to support it given
my current understanding of it (not that either my support or opposition
is worth very much).  But I'd be curious to explore the idea further and
see where it might lead.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 19 Sep 2007 03:44:29 +0000

> ... If we fail to provide good ways, consenting adults might (and
> usually do) come up with worse ways.

is that how you characterize NAT, firewalls, and application layer gateways?

utk-mail11 may have seemed to you like a way to extend the internet, but
to the greybeards of the time who had crapped upon bitnet and uucp, decnet
mail11 (for example, DECWRL.ENET.DEC.COM) was an abuse of the MX RR, not a
"good way" to use the technology.  firewalls and NAT, by making it harder
to carry real packets from one endpoint to another, were seen as heresy.
do you think that these are "worse ways" that wouldn't've come about had
the IETF provided "good ways"?  if so can i hear an example of a better way
that wouldn't be seen as a total departure from "the internet way of doing
things", just to help me frame your position?

> It's not that consenting adults shouldn't be able to solve their own
> problems, it's that some kinds of solutions can and do cause harm for the
> Internet, particularly when they're widely deployed.

i can see how a *.COM wildcard, or any TLD wildcard, fits that description.

i can't see how DNSSEC DLV, or ULA-C, fits that description.

at the moment, they are all condemned using the same buzzwords.  i'm asking
that the ones without objectively verifiable immediate harm not be crapped on.

> p.s. And FWIW, in the message where I said 'It's hard for me to buy the idea
> of there not being a "core" portion of the Internet from which all public
> addresses are reachable' what I meant was that I have a hard time imagining
> the conditions which would make it happen, not that I would try to stop it
> from happening.  I'd be hard pressed to support it given my current
> understanding of it (not that either my support or opposition is worth very
> much).  But I'd be curious to explore the idea further and see where it
> might lead.

that's a useful clarification.  but it changes nothing.  if other people, who
are not you, and who are consenting adults, want to interoperate using
prefixes under the ULA /7 prefixes but having, unlike RFC 4193 ULA prefixes,
globally visible whois and in-addr support, then it's not your place to tell
them they shouldn't want that or shouldn't have that.

---

From: "Stephen Sprunk" <[email-masked]>
Date: Tue, 18 Sep 2007 16:06:07 -0500

Thus spake "Iljitsch van Beijnum" <[email-masked]>
>> I don't think ULA-C makes sense. We have a RIR system in
>> place. These RIRs are supposed to provide address space
>> for people/organizations who can justify a need for that
>> address space.
>
> That's like selling train tickets at the airport. Except for the  fraction 
> of a promille of all IP users that have their own portable  address space, 
> RIRs don't even talk to IP users who are
> _connected_  to the internet, let alone those who aren't! It just
> doesn't make sense to involve the RIRs here.

The RIRs talk to anyone who submits the appropriate forms.  They'll even 
help you fill out the forms if you can give them enough information to do 
so.  You could even do it by phone or snail mail if you've been living under 
a rock and still don't have Internet service.

ARIN policy, at least, explicitly allows for direct assignments to end sites 
even if they're not connected -- just like IANA assigned Class A/B/C blocks 
to disconnected orgs back in the good ol' days.

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: "Stephen Sprunk" <[email-masked]>
Date: Tue, 18 Sep 2007 16:01:09 -0500

Thus spake "Tony Hain" <[email-masked]>
> Jari Arkko wrote:
>> Right. Or we can try to label it, but that labeling may not
>> correspond to what is actually done with it.
>
> If you don't label it there is no clearly agreed way to filter these out
> if you don't want them.

If they're truly "local" prefixes, they won't need to be filtered in the 
first place because they won't be advertised.  If they're getting 
advertised, they're not "local" prefixes and presumably you don't want to 
filter them because there's someone at the other end who wants you to talk 
to them.

If you don't like PI routes at all, the RIRs have made it easy to filter 
them by assigning PI out of specific blocks and in much smaller sizes than 
LIR blocks.  To channel Randy for a moment, I encourage my competitors to do 
this.

> The people that are fighting having ULA-C are the same ones
> that don't want PI, and they are trying to force ULA-C == PI so
> they can turn that argument around and say 'we told you PI was
> a bad idea' when there is no way to filter out what would have
> been ULA-C.

I am a vocal supporter of PI and vocal detractor of ULA-C/G.  In fact, the 
first time that ULA-C was proposed, I saw it for what it was (an end-run 
around the RIRs) and became a PI proponent; before that, I didn't really 
care either way.

Do not stuff words into people's mouths, particularly when they're watching.

> If you really believe there is going to be a routing system
> problem, then you absolutely have to support ULA-C because
> it is the only way to enforce keeping private space private.

I believe there will be a routing system problem at some point, and it pains 
me that I was still forced to support PI anyways because the IETF has 
utterly failed to produce an alternative that is viable _in the views of the 
operational community_.

However, I do not believe the "problem" will be due to "local" routes at 
all; it will be due to the massive numbers of legitimate routes that having 
PI causes.  However, without PI, there would be no routes at all because 
IPv6 would be ignored.  PI is, unfortunately, the lesser of two evils.

S

---

From: Keith Moore <[email-masked]>
Date: Wed, 19 Sep 2007 01:21:55 -0400

Paul Vixie wrote:
> "good way" to use the technology.
boy, that takes me back...

Actually, it probably _was_ an abuse of the MX RR - perhaps not so much
in the case of ENET.DEC.COM (presuming that everything connected to
DEC's DECnet belonged to DEC, it was reasonable for DEC.COM to create
alternate names for its own user communities), but moreso when a single
zone like DNET.UTK.EDU was used to map to hosts like UTMEM that were
connected to UTK's DECnet but which weren't administratively under UTK.

On the other hand, that gateway and that use of MX records helped to
unify addressing and message formats and provide a more uniform user
experience and eventually a cleaner transition to pure Internet based
mail.   And once the gateway was in place and the hosts on our DECnet
got better internet mail connectivity, I was able to get MX records
setup in appropriate zones, and have our gateway rewrite outgoing mail
to use those DNS names.  You could still send mail to
[email-masked] and it would get forwarded to xxx::user, but
people pretty quickly adopted the new names.  That wasn't part of the
original plan for the gateway, but the gateway made it easy to do that. 
(And actually I think that somewhere along the way, the idea for doing
that might have come as a result of some feedback from one of those
greybeards.)

I was pretty naive in those days about potential effects of such
things.  Today, one of my litmus tests for whether something that
violates the architecture is a Good Idea or not is to look at the likely
end state.  Will the hack lead to an ugly end state or is there an
attractive transition path to a clean end state?  In the case of
utk-mail11, there was an attractive path to a clean end state.  Having a
DECnet gateway that allowed exchange of mail with the Internet without
needing a percent-hack or bangpath or ugly quoted address with an
embedded "::" was more attractive than the alternatives.  Having "real"
DNS names for those hosts (via MX records in their own zones) pointing
to the gateway was more attractive still.  And eventually, having native
IP connectivity for those hosts was even more attractive.

NAT is an example of a hack that led to an ugly end state.  But an
alternate version of NAT, call it NAT-prime, could perhaps have created
a transition path to IPv6.
>   firewalls and NAT, by making it harder
Today, I think I could describe a better NAT (and I might try to do that
before Vancouver).  I would have had a harder time doing so in the mid
1990s.  But even then, if we had had the notion of trying to build
temporary fixes that help to promote a more desirable end-state, NAT
could have been a lot better than it turned out to be.  Also I don't
think we did a good job of analyzing the likely effect of NAT - actually
I think there was a fair amount of denial there, or at least a tendency
to pull punches and avoid saying just how bad they were.

I think we're maybe a bit too purist - but only a bit.   We need to be
evaluating these things not in terms of how architecturally pure they
are, but by actually analyzing their effects.  I seem to recall we've
done that for some hacks - like traffic shapers, maybe - but have been
very reluctant to do so for others, like ALGs.  Analysis can be flawed,
of course, but it's better than religious arguments about purity.
> that the ones without objectively verifiable immediate harm not be crapped on.
"objectively verifiable" may be too strong.  ("immediate harm" certainly
is.)  It's like demanding that global warming be objectively verifiable
by watching the polar ice caps melt and proving that it's due to
pollution.  (Even if the ice caps do melt, there will still be people
claiming that it's an entirely natural phenomenon.  Either that or
divine will.)

But I do think that an analysis of the effects of a hack is in order. 
And I think that for any proposal that has the potential to have
widespread effect on the Internet architecture, the burden is on the
proposers to argue convincingly that the hack will do no lasting harm
and that it will encourage a desirable end-state, before the IETF
community should back it - or even agree to publish it.
> them they shouldn't want that or shouldn't have that.
surely I can make whatever recommendations I see fit, supporting those
recommendations with the best arguments that I can come up with.   and
people can heed them or not as they see fit.

as for IETF: if something's a bad idea, IETF shouldn't be compelled to
endorse it by publishing it as an RFC.  and if there's a community
consensus within IETF that it's a bad idea, IETF should be able to
criticize it.

Keith

---

From: Paul Vixie <[email-masked]>
Date: Wed, 19 Sep 2007 05:42:20 +0000

> On the other hand, that gateway and that use of MX records helped to unify
> addressing and message formats and provide a more uniform user experience
> and eventually a cleaner transition to pure Internet based mail.  And once
> the gateway was in place and the hosts on our DECnet got better internet
> mail connectivity, I was able to get MX records setup in appropriate zones,
> and have our gateway rewrite outgoing mail ...

sounds like a cool hack.  it's good that you didn't need any standards work
to support your project, or it would have been killed by folks who thought
you shouldn't do it that way, because of some kind of latent harm you and
your fellow consenting adults might do each other.

> I was pretty naive in those days about potential effects of such things. ...

thank goodness for that.

> Today, one of my litmus tests for whether something that violates the
> architecture is a Good Idea or not is to look at the likely end state.  Will
> the hack lead to an ugly end state or is there an attractive transition path
> to a clean end state?  ... Having "real" DNS names for those hosts (via MX
> records in their own zones) pointing to the gateway was more attractive
> still.  And eventually, having native IP connectivity for those hosts was
> even more attractive.

mark horton and a cast of hundreds did the same thing in the UUCP Project.
and this abuse of the MX RR brought thousands of sites to the internet since
"e-mail only" wasn't a desireable state once they had their own domain names.

> NAT is an example of a hack that led to an ugly end state.  But an alternate
> version of NAT, call it NAT-prime, could perhaps have created a transition
> path to IPv6.

was it offered?  and with more specifics than that?  or did the people who
said "NAT would be bad" pretty much say no more than that, expecting somehow
that the great unwashed masses, having been turned away from the temple, would
to back to their hovels and wait for the enlightenment?

> evaluating these things not in terms of how architecturally pure they are,
> but by actually analyzing their effects.  I seem to recall we've done that
> for some hacks - like traffic shapers, maybe - but have been very reluctant
> to do so for others, like ALGs.  Analysis can be flawed, of course, but it's
> better than religious arguments about purity.

only a bit?  how much is too much and how would you prove it?  analysis that
proves harm to third parties should be heard.  hand-wringing about the dangers
to participants or the waste of time should not be heard so much.

> But I do think that an analysis of the effects of a hack is in order.  And I
> think that for any proposal that has the potential to have widespread effect
> on the Internet architecture, the burden is on the proposers to argue
> convincingly that the hack will do no lasting harm and that it will
> encourage a desirable end-state, before the IETF community should back it -
> or even agree to publish it.

that's the current state, and owing in part to the impossibility of proving
a negative, it's not working very well.

> recommendations with the best arguments that I can come up with.  and people
> can heed them or not as they see fit.
> 
> endorse it by publishing it as an RFC.  and if there's a community consensus
> within IETF that it's a bad idea, IETF should be able to criticize it.

thanks for the chat, i'm even more sure where i stand now than i was before.

---

From: Keith Moore <[email-masked]>
Date: Wed, 19 Sep 2007 02:02:19 -0400

> your fellow consenting adults might do each other.
well, the MX standard _did_ support that project.  if MX support hadn't
been widespread by then, it wouldn't have worked.  (and indeed, it
wouldn't have worked in the mid-1980s as too many systems at that time
still relied on HOSTS.TXT.   really, it was only after the Morris Worm
forced people to upgrade their sendmails that MX really started to take
hold.  even then, a lot of vendors didn't ship sendmails with MX support
turned on by default.)

> to back to their hovels and wait for the enlightenment?
something you are missing is that a lot of the "NAT would be bad"
messages also got suppressed.    it's not as if NAT got killed because
people in IETF objected to it.   it's more like IETF's unwillingness to
look beyond NAT to the underlying problems (other than address space
exhaustion) that made NAT attractive caused IETF to miss an opportunity
to produce something better.

(something we really have a hard time doing in IETF is packaging a
solution in such a way that it will be attractive.  we tend to work on
things in a piecemeal fashion, leaving some parts of the problem
unsolved, and hoping that vendors will fill in the gaps)
> to participants or the waste of time should not be heard so much.
again, I think the burden needs to be on the proposers to demonstrate
that what they're proposing is overall a good thing.  I think the
community, and IESG, should expect thorough analysis of anything that
could potentially have widespread effect.   hand-waving about the
benefits of an idea is no more useful than hand-wringing about the
dangers.  but analysis beats hand-wringing.
> a negative, it's not working very well.
as far as I can tell, the current state is that we don't expect such
analysis in the vast majority of cases, the proposers don't provide it,
and the decision gets made by handwaving and handwringing.
> thanks for the chat, i'm even more sure where i stand now than i was before.
well, I have to wonder why you think that someone should be able to
compel IETF to support his proposal without getting community consensus.

Keith

---

From: <[email-masked]>
Date: Wed, 19 Sep 2007 08:41:47 +0100

> the concern i heard wrt ULA-G (and therefore wrt ULA-C upon 
> with -G is based) is that the filtering recommendations in 
> RFC 4193 were as unlikely to "work"
> as the filtering recommendations in RFC 1597 and RFC 1918.  

Given the overwhelming success of RFC 1918 it only requires a very small
percentage of sites leaking routes to make it seem like a big problem.
This is normal. When you scale up anything, small nits happen frequently
enough to become significant issues. But that is not a reason to get rid
of RFC 1918.

The fact that the filtering recommendations of ULA-C and ULA-G have the
same flaws as RFC 1918 is a not sufficient reason to reject them
wholesale.

> i realized in 
> that moment, that ULA-G (and therefore ULA-C) is not an end 
> run around PI space, it's an end run around the DFZ.  some 
> day, the people who are then responsible for global address 
> policy and global internet operations, will end the "tyranny 
> of the core" by which we cripple all network owners in their 
> available choices of address space, based solely on the 
> tempermental fragility of the internet's core routing system. 
>  but we appear not to be the generation who will make that leap.

I think that even today, if you analyze Internet traffic on a global
scale, you will see that there is a considerable percentage of it which
"bypasses" the core. Let the core use filters to protect the DFZ because
the DFZ is no longer necessary for a workable Internet.

--Michael Dillon

---

From: Roger Jorgensen <[email-masked]>
Date: Tue, 18 Sep 2007 18:05:32 +0200 (CEST)

On Tue, 18 Sep 2007, Tony Hain wrote:
<snip>
> because it is the only way to enforce keeping private space private.

PI and ULA-C are for completly different purpose.
and both will be leaked no mather what we do, you can't force someone to 
never route it... what you can do is to make it less desirable to do so.

-- 

------------------------------
Roger Jorgensen              | - ROJO9-RIPE  - RJ85P-NORID
[email-masked]           | - IPv6 is The Key!
-------------------------------------------------------

---

From: Roger Jorgensen <[email-masked]>
Date: Tue, 18 Sep 2007 18:05:32 +0200 (CEST)

--

---

From: Roger Jorgensen <[email-masked]>
Date: Tue, 18 Sep 2007 21:35:24 +0200 (CEST)

On Tue, 18 Sep 2007, Paul Vixie wrote:
<snip>
> generation who will make that leap.

I wouldn't be giving up that easy... still have time until march 2008 
:p (old ipv6-wg, now v6man-wg timeframe for deciding upton ula-c/g) :)

-- 

________
Ietf mailing list
[email-masked]

---

From: Roger Jorgensen <[email-masked]>
Date: Tue, 18 Sep 2007 18:05:32 +0200 (CEST)

--

---

From: Roger Jorgensen <[email-masked]>
Date: Tue, 18 Sep 2007 21:35:24 +0200 (CEST)

--

---

From: "Stephen Sprunk" <[email-masked]>
Date: Wed, 19 Sep 2007 10:15:50 -0500

Thus spake "Michael Richardson" <[email-masked]>
> of such cabinets spread around the world.
...
> rfc1627. (ARIN has suggested that I might consider site-local addresses)

I hope you misunderstood; ARIN should have been referring to ULAs, RFC 4193.

> the IPv4 policy currently in effect.

That is correct.

> (none of the other rfc1918 spaces are big enough for my use, btw)

That is not.  ARIN policy is that private addresses are preferred, but 
public addresses can be assigned for private use if there's a decent 
justification.  Also note that actually _requesting_ PIv4 space is not 
required to get PIv6 space; only _qualifying_ is required.  You appear to 
qualify based on the limited information provided.

> I am simply posting to express myself.

You appear to qualify for a PI /48 (or more than one) under existing policy. 
If you are unhappy with the policy or need a better explanation, please join 
[email-masked] and ask for help.  If you do not believe ARIN is following the 
existing policy, please contact [email-masked].

S

---

From: "Stephen Sprunk" <[email-masked]>
Date: Wed, 19 Sep 2007 10:15:50 -0500

...

That is correct.

S

---

From: Paul Vixie <[email-masked]>
Date: Wed, 19 Sep 2007 15:27:37 +0000

> it's not as if NAT got killed because people in IETF objected to it.

yes, but do you think that was because that ietf was powerless to stop it, or
because that ietf was willing to let consenting adults try out new ideas?  i
was there, and from what i saw, it was the former.

> it's more like IETF's unwillingness to look beyond NAT to the underlying
> problems (other than address space exhaustion) that made NAT attractive
> caused IETF to miss an opportunity to produce something better.

the underlying problem was that people in the field didn't want universality
among endpoints, either for security or policy reasons, and people in that
ietf wanted universality among endpoints -- a single addressing system and
a single connectivity realm.  that ietf said, you don't really want that, you
should use the internet as it was intended, and solve the problems you're
having in some way that preserves universality of endpoints.  the field said,
you are completely out of your minds, we're going to ignore ietf now.  then
later on, ietf said, if you're going to do it, then we ought to help you with
some standards support.

i'm at the "ignore ietf now" stage with things like DNSSEC DLV, and it's going
to come as no shock to me if SIXXS is at the "ignore ietf now" stage with ULA.

all it takes is a couple of loud or influential people to prevent consensus
from forming.  the quality of the idea or its potential to shape human events
is at best a secondary ingredient in the ietf mix.

which is why i'm proposing a standard of "demonstrable immediate harm" rather
than the current system of "that's not how you should do it" or "that's not
how i would do it".

> that what they're proposing is overall a good thing.

that's just not possible.  and it hasn't been behind any stunning success ever,
although there are some stunning failures i think i could lay at that doorstep.

---

From: "Stephen Sprunk" <[email-masked]>
Date: Wed, 19 Sep 2007 10:41:50 -0500

Thus spake <[email-masked]>
> The fact that the filtering recommendations of ULA-C and ULA-G
> have the same flaws as RFC 1918 is a not sufficient reason to
> reject them wholesale.

Actually, the flaws are different because ULA-C/G leaks will not collide 
with each other.  This means that, unlike RFC1918 which is _impossible_ for 
ISPs to route for multiple customers, ULA-C/G routes _can_ be routed 
publicly.  Any prohibition on doing so by the IETF or RIRs can (and IMHO, 
will) be overridden by customers paying for those routes to be accepted. 
The IETF has zero enforcement capability.

Since some RIRs have PI, the odds of that happening have been reduced (which 
was a major motivation for PI being accepted), but many folks who are asking 
for ULA-C/G are ones that do not qualify under current PI policies and/or 
are served by RIRs that haven't adopted PI at all.

S

---

From: "Stephen Sprunk" <[email-masked]>
Date: Wed, 19 Sep 2007 10:41:50 -0500

S

---

From: Keith Moore <[email-masked]>
Date: Wed, 19 Sep 2007 12:08:38 -0400

> was there, and from what i saw, it was the former.
IETF has very little power, if you can call it that.  IETF can try to
suggest good ways of doing things quickly enough that the good ways get
adopted before bad ways do, or it can recommend against bad ways of
doing things.  The former is much more effective.  It pretty much failed
to do either in the case of NAT.  I remember a lot of concern being
expressed, but a strong reluctance to make any statement - perhaps due
to lack of consensus about how bad NATs were and what, if anything,
could be proposed as a better way.
> later on, ietf said, if you're going to do it, then we ought to help you with
That's not quite how I remember it from my POV.  Some people were very
concerned about ambiguous addressing.  I don't think universal
connectivity was as big a concern - it's not like IETF people expected
everyone to run open networks.   But mostly there was a lot of unease
and uncertainty about NATs.  Very little analysis was done.  And I don't
think that NAPTs were initially seen as the normal case.
> from forming.  
and quite often (not always, but often), those people are right.
> thanAB103661;
	Wed, 19 Sep 2007 12:08:49 -0400 (EDT)
Date: Wed, 19 Sep 2007 12:08:38 -0400
From: Keith Moore <[email-masked]>
To: Paul Vixie <[email-masked]>
OpenPGP: id=E1473978
Cc: 'IETF Discussion' <[email-masked]>
Subject: Re: ideas getting shot down

> was there, and from what i saw, it was the former.
IETF has very little power, if you can call it that.  IETF can try to
suggest good ways of doing things quickly enough that the good ways get
adopted before bad ways do, or it can recommend against bad ways of
doing things.  The former is much more effective.  It pretty much failed
to do either in the case of NAT.  I remember a lot of concern being
expressed, but a strong reluctance to make any statement - perhaps due
to lack of consensus about how bad NATs were and what, if anything,
could be proposed as a better way.
> later on, ietf said, if you're going to do it, then we ought to help you with
That's not quite how I remember it from my POV.  Some people were very
concerned about ambiguous addressing.  I don't think universal
connectivity was as big a concern - it's not like IETF people expected
everyone to run open networks.   But mostly there was a lot of unease
and uncertainty about NATs.  Very little analysis was done.  And I don't
think that NAPTs were initially seen as the normal case.
> from forming.  
and quite often (not always, but often), those people are right.
> than the current system of "that's not how you should do it" or "that's not
That's the wrong standard, it sets the bar way too low.  IETF shouldn't
endorse anything unless it has justification to believe it is good; IETF
should not discourage anything unless it has justification to believe it
is bad.   And that justification should come from engineering analysis
(or measurement, if it's feasible).  Sadly, a lot of people in IETF do
not have engineering backgrounds and don't understand how to do such
analysis.  This is something we need to change in our culture.

Keith

 the current system of "that's not how you should do it" or "that's not
> how i would do it".
That's the wrong standard, it sets the bar way too low.  IETF shouldn't
endorse anything unless it has justification to believe it is good; IETF
should not discourage anything unless it has justification to believe it
is bad.   And that justification should come from engineering analysis
(or measurement, if it's feasible).  Sadly, a lot of people in IETF do
not have engineering backgrounds and don't understand how to do such
analysis.  This is something we need to change in our culture.

Keith

---

From: Eliot Lear <[email-masked]>
Date: Wed, 19 Sep 2007 19:15:25 +0200

Paul Vixie wrote:
> "public networking".

Without going into debate about consenting adults, and while I might 
disagree with Paul in certain fine points, I'd suggest that we consider 
the ULA-G proposal within the IETF and ask that Paul submit it as an 
I-D.  ULA-G could have broad application if in fact we solve the 
multihoming problem (IMHO) and I'd like to be the optimist and say that 
we can do that.

Eliot

---

From: Michael Thomas <[email-masked]>
Date: Wed, 19 Sep 2007 10:21:37 -0700

> analysis.  This is something we need to change in our culture.

Feh, that seems awfully self-important to me (where "self" == "ietf").
"The IETF" (putting aside that it isn't a hive mind) isn't the ultimate
arbiter of good and bad, or useful/useless. Often there is utility to the
notion of "if you're doing to do this questionable thing, at least do this
questionable thing consistently". What you're advocating toes the best
is the enemy of the good line. Nothing would make the IETF
irrelevant faster than crossing that line.

       Mike

---

From: Keith Moore <[email-masked]>
Date: Wed, 19 Sep 2007 13:27:01 -0400

> arbiter of good and bad, or useful/useless. 
Of course not.  But why should the IETF represent something as its
opinion when the IETF doesn't actually have that opinion?  And why
should the IETF , given that it claims to be an engineering body,
express an opinion that is based on mere handwaving?  Doing either of
these can only harm our reputation.
> Often there is utility to the notion of "if you're doing to do this
> questionable thing, at least do this questionable thing consistently". 
Actually I keep wishing that we had a way to say "if you're going to
engage in this dubious or harmful practice, at least do it this way that
seems less harmful than other ways".    Because we too often get stuck
between having justification for saying that some practice is bad, but
not having consensus on a "good" way to solve the problem, or not having
a "good" solution worked out in sufficient detail.

Keith

---

From: Eliot Lear <[email-masked]>
Date: Wed, 19 Sep 2007 19:42:21 +0200

> "good way" to use the technology.  

Here our views of history differ.  I can't say that I had a gray beard 
at the time, nor that I was at all involved in the design, but I was 
there, and I think there was something of a view that the whole point of 
MXes was for the MX relay to bridge between online and offline devices.  
It was well understood at the time that MANY more systems were in fact 
on the networks that you mentioned than were on the ARPANET.  And I 
would even argue that there MXes solved a major problem, which was that 
there was that sites that sat on both UUCP and the Internet often times  
Got It Wrong with regard to the precedence of "!".  The abstraction that 
MX provided made relaying behavior much more explicit.  I think this was 
understood at the time.

Regards,

Eliot

---

From: Keith Moore <[email-masked]>
Date: Wed, 19 Sep 2007 13:58:12 -0400

Eliot Lear wrote:
> there, and I think there was something of a view that the whole point
> of MXes was for the MX relay to bridge between online and offline
> devices.  It was well understood at the time that MANY more systems
> were in fact on the networks that you mentioned than were on the
> ARPANET.  And I would even argue that there MXes solved a major
> problem, which was that there was that sites that sat on both UUCP and
> the Internet often times  Got It Wrong with regard to the precedence
> of "!".  The abstraction that MX provided made relaying behavior much
> more explicit.  I think this was understood at the time.
I think the argument was really that putting another network's name
space within a DNS zone did not make good sense, particularly when that
network crossed administrative boundaries.   Of course (just like today)
the argument was not always expressed with sufficient clarity, so
sometimes what came out was "what you are doing is Bad!"

This was also back in the day when people seriously argued that DNS
should only be used for host names.  They didn't understand that the
concept of "host" was going to get fuzzier and less relevant over time.

Keith

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 19 Sep 2007 12:06:10 -0700

Ted Hardie wrote:
> nothing

It is clear that people on this list have never really run a network as they
appear to be completely missing the point, but there is no reason to respond
to each individually...

Yes any one clueless ISP may announce ULA-C space from a customer, but there
is no need for any of their peers to accept it. If the only choice is PI,
there is no way for the peer ISP to know what should have been filtered out
and the entire system has to deal with the leakage. Claims about cutting off
long prefixes are unrealistic because there will be people in there that
received PI expecting it to be routed so the RIRs would then have to hand
out even larger blocks for routed PI, forcing the cost for renumbering onto
people that had nothing to do with creating the problem. 

People want unique private space. If you force them to get it from PI blocks
there is no way to sort out what should be globally routed from what should
be private, or localized to just the customer's ISP. Putting a well-known
label on it allows anyone that does not want the excess to easily identify
it and kill it off. Using ULA-C puts the burden of getting space routed
globally back onto the originating network, because they will either run
both ULA-C & PI, or renumber. Either way people who just want PI are not
impacted by people that start with ULA-C and change their minds later, and
the DFZ does not have to deal with leaked crap because it is easy to
identify. 

This should not even be a debated issue, because ULA-C is just a way to
group end site assignments into a block that is easy to filter out of the
global routing system. As I said, those that oppose this are effectively
forcing an unnecessary burden on the DFZ, which will result in the anti-PI
camp saying 'I told you so' when the inevitable leakage happens. Yes 1918
leakage happens, but that is a self-inflicted wound and easy to correct, as
ULA-C leakage would be. Leakage of PI that should have been kept local is
impossible to detect or fix by the recipient. 

Tony

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 19 Sep 2007 22:11:11 +0200

On Wed, Sep 19, 2007 at 12:50:44AM +0000,
 Paul Vixie <[email-masked]> wrote 
 a message of 32 lines which said:

> in the IETF, the naysayers pretty much kick the consenting adults'
> asses every day and twice on sunday.  and that's the real problem
> here, i finally think.

Time to have a formal representation of end-users at the IETF?

http://patrick.vande-walle.eu/internet/how-can-the-engineering-community-and-the-users-meet/

(My personal worry about this proposal is that there is zero
organisation of end-users at this time. ALAC, mentioned by Vande
Walle, is a complete failure.)

---

From: Jeroen Massar <[email-masked]>
Date: Wed, 19 Sep 2007 23:29:34 +0100

> Time to have a formal representation of end-users at the IETF?

What is defined as an 'end-user'?

You, me, the rest of the people, are all end-users IMHO.

That we might have quite a bit more knowledge on how things work and
that we might have some connections to people so that we can arrange
things, is nothing of an advantage over people who are not technically
inclined (or how do you put that nicely ;)

The point is that those people don't know better and as such they also
don't know what is possible and what they are missing.

Eg, if you tell somebody "oh but I have a /27 IPv4 and a /48 IPv6 at
home and I can access all my computers from the Internet wherever I am",
they will be going "and? why would I need that". The typical lay-man
end-user really couldn't care less, as long as their stuff works.

The only people really noticing problems with this are hobbyists and
most likely the gaming crowd trying to setup their own gameserver and
finding out that they are stuck behind this thing called "NAT".

P2P people, thus quite a large group of people using the Internet today,
have their tools to nice NAT tricks, thus these won't notice it.

And for the rest of the population the Internet consists of http:// and
https:// if they even recognize those two things, thus most likely only
"www" and "email", the latter likely only over a webinterface...

Which group do you want to 'involve' in the IETF and more-over, why?
Last time I checked the IETF was doing protocols and not user interfaces.

Greets,
 Jeroen

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 19 Sep 2007 15:43:00 -0700

>Walle, is a complete failure.)

Given that ICANN's ALAC is the example that has had the most effort 
put behind it, and it is indeed a complete failure, why do you think 
the IETF would do any better? Or, even if we did do better in the 
long run, that the huge amount of effort it would take would not have 
been better spent on technical matters?

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Vixie <[email-masked]>
Date: Wed, 19 Sep 2007 23:22:52 +0000

> disagree with Paul in certain fine points, I'd suggest that we consider the
> ULA-G proposal within the IETF and ask that Paul submit it as an I-D.  ULA-G
> could have broad application if in fact we solve the multihoming problem
> (IMHO) and I'd like to be the optimist and say that we can do that.

i'll need new coauthors.  i ain't signing up for this alone, and the authors
of ULA-C only wrote it up so that we would all know what ideas had been
abandoned, not as a way forward.

---

From: Ole Jacobsen <[email-masked]>
Date: Wed, 19 Sep 2007 17:06:20 -0700 (PDT)

I think this largely depends on what is defined as an "end-user". The 
reason the ALAC is failure is that there is a complete mismatch 
between the stuff ICANN does and what these "end users" THINK ICANN 
does or should be doing. 

The ALAC members are largely made up of "civil society" or "political 
science" folks with an agenda and a strong passion for international
travel -- and most of all a desire to be HEARD, no matter how 
irrelevant their topic is.

The only thing I could suggest that would make sense in the case of 
the IETF would be an improved linkage to the OPERATOR community (e.g. 
NANOG), but I don't really think the IETF wants or needs to hear from
my father, born in 1919, even if he is indeed an Internet "end-user".

Ole

Ole J. Jacobsen
Editor and Publisher,  The Internet Protocol Journal
Cisco Systems
Tel: +1 408-527-8972   Mobile: +1 415-370-4628
E-mail: [email-masked]  URL: http://www.cisco.com/ipj

On Wed, 19 Sep 2007, Paul Hoffman wrote:
> 
> Given that ICANN's ALAC is the example that has had the most effort put behind
> it, and it is indeed a complete failure, why do you think the IETF would do
> any better? Or, even if we did do better in the long run, that the huge amount
> of effort it would take would not have been better spent on technical matters?
> 
> --Paul Hoffman, Director
> --VPN Consortium
>

---

From: Jeroen Massar <[email-masked]>
Date: Thu, 20 Sep 2007 00:54:56 +0100

And in another mail wrote:
> i'm at the "ignore ietf now" stage with things like DNSSEC DLV, and
> it's going to come as no shock to me if SIXXS is at the "ignore ietf
> now" stage with ULA.

My view on the ULA story and for that matter any address space being
given out is much simpler and it has nothing to do with ignore, it has
to do with what is realistic. That "ULA registry" is just to demonstrate
that a very cost effective (aka 0.0EUR cost) way can be setup where
people can register their prefixes if it really is so important for them
to have that little bit more certainty that they are 100% unique instead
of the collision probability of 4.54*10^-05 even when having 10k
connections to other ULA sites. If IANA would want to run similar code I
am very happy to provide them with the details etc on how to do it,
though I am fairly sure they can easily do it themselves too.

Currently organizations need IPv6 address space. ARIN/APNIC/AfriNIC
allow them to get a nice /48, or larger if they can justify that. In
RIPE land you just become LIR and get a /32 along with it. This allows
them to deploy IPv6 today.

As for organizations wanting 'disconnected' address space, just go to
your RIR and get it. There is (except for AfriNIC) no requirement
anywhere to announce the space in the DFZ. If you don't want to go to an
RIR, go to an LIR who have a /32 and just ask them for a /48, and pay
them a 100 EUR or something for 'administrative fees' or whatever. That
is why LIRs exist. This is also what happens today with IPv4 address space.

IMHO The /48 "PI" thing is a good thing. Except that in my view of
things in a year or 10-20 they won't be floating in the DFZ any more.

The DFZ as we know it will be a real Tier system. Only the "Tier 1s and
Tier2s", the current organizations who get the /32's and up will be in
there. All the 'small' parties, thus the /40 - /48's will be using a
non-BGP method of connecting up to the Internet and thus won't
contribute to DFZ re-calculations.

Routing will become more 'geographic', the only thing you will need to
know is that "Organization X is a customer of transit Z and Y and they
prefer Z", you have a BGP route to transit Z and simply send your
packets there. When transit Z flaps around, then you only need 1 update,
not 100000, which are their customers. Still you will have some state
which can be updated in near-real-time, where X will say "please send
packets destined to me preferably over Y" or "Transit W is now our
preferred transit, use them please".

In my vision the /48s being given out as "PI" today can be used for the
ID portion, while every transit will give a "location" /48 to the site
that needs it. Over the DFZ the src/dst will be in DFZ/location style,
but when it arrives at the endsite it will be in PI mode again. NAT
(that evil thing) is useful and when you do it twice you actually still
have the same packet and have achieved a tunnel without the overhead of
it. The signaling of what to use is the tricky part though.

See [email-masked] for more of those discussions. Those folks are doing
good work.

It might indeed not be ready tomorrow, not next year, maybe not in the
next 10 years, but really current routing hardware will scale up to
that. Remember, only 900 IPv6 routes today and only 1517 prefixes have
really been allocated from the RIRs to the ISPs and I don't see another
200k popping out of nowhere anywhere soon. I could be very wrong of
course though :)

Who can be Tier1 or 2 will then be determined based on cash,
connectivity and weight; eg YouTube and Google for instance can do
pretty much they want, if they do www.google.com A 1.2.3.4, 1.0.0.0/8
will most likely quickly be theirs, just because otherwise you will have
your customers whining that you broke the Internet.

Greets,
 Jeroen

---

From: "Michael Froomkin - U.Miami School of Law" <[email-masked]>
Date: Wed, 19 Sep 2007 20:27:38 -0400 (EDT)

I'd be careful about using the ICANN/ALAC example as proving much of 
anything other than if a group wishes to set up some window-dressing so it 
can say users are consulted, and ensures that the users have no particular 
influence in the group's activities (compared to every other represented 
interest group), that then you get an ineffective outcome.

I'd expect that in the unlikely event the IETF were to go down this road, 
they would actually use Internet tools to organize people and discussions, 
and that the process would be colored with far more good sense, good faith 
and good will.

That doesn't mean it would work or that you should do it -- the obstacles 
are real and serious -- just that I don't think you can generalize from a 
process, the ALAC, that was not engineered to work so much as to generate 
good news coverage.  Indeed, ALAC is there because there was some powerful 
end-user representation in ICANN 1.0, and the powers that be didn't like 
the Mensheviks.

On Wed, 19 Sep 2007, Paul Hoffman wrote:

> Given that ICANN's ALAC is the example that has had the most effort put 
> behind it, and it is indeed a complete failure, why do you think the IETF 
> would do any better? Or, even if we did do better in the long run, that the 
> huge amount of effort it would take would not have been better spent on 
> technical matters?
>
> --Paul Hoffman, Director
> --VPN Consortium
>

-- 
http://www.icannwatch.org   Personal Blog: http://www.discourse.net
A. Michael Froomkin   |    Professor of Law    |   [email-masked]
U. Miami School of Law, P.O. Box 248087, Coral Gables, FL 33124 USA
+1 (305) 284-4285  |  +1 (305) 284-6506 (fax)  |  http://www.law.tm
                        -->It's warm here.<--

---

From: Lynnold M Wini <[email-masked]>
Date: Thu, 20 Sep 2007 11:45:31 +1100

My very first contribution to this mailing list - pardon me, I am 
nervous  :-) .

I agree  with suggestion that it would make more sense to improve 
linkages "to the OPERATOR community (e.g.NANOG)" as opposed to the end-user.
I follow the discussions on this forum but admit that although 
technically inclined, sometimes these discussions are simply beyond me 
and I tend to think that the focus is so much on the needs of the 
developed world that hardly anything is relevant nor takes the Pacific 
situation into consideration.

Having said that I  believe if IETF were to pursue improved linkages 
through the OPERATOR community, in our case PACNOG - it would generally 
improve our knowledge on what is happening within IETF as ultimately the 
decisions made at this level affect everyone (end-users) using the Internet.

The onus, of course, would be on us (in the pacific) to build our 
capacity to comprehend and actively participate in IETF processes, but I 
agree the operator community would be a great starting point.

Lynnold M Wini

Solomon Telekom Co Ltd
Honiara,
Solomon Islands

---

From: Keith Moore <[email-masked]>
Date: Thu, 20 Sep 2007 00:30:45 -0400

> it. The signaling of what to use is the tricky part though.
I think that dual NAT can be used in a somewhat benign way.  If it's
done by bilateral agreement between networks with globally unique
prefixes, and the mappings at each end are symmetrical, it seems like
it's basically equivalent to a tunnel with a kind of header compression
and without the PMTU reduction issues.  And if the addresses used at the
host are unique, it gets rid of many of the problems caused by
overlapping use of RFC 1918 addresses in IPv4.  There's still some
issues related to traceability of traffic over the network, but maybe
those are manageable.

---

From: Peter Dambier <[email-masked]>
Date: Thu, 20 Sep 2007 10:18:04 +0200

Interesting discussion.

I am envolved in two groups develloping around OpenWRT.

One group (some 2000 members) is trying to TORify a < dollar 150 router
the other group (some 30 members) is trying to IPv6 that very same
software. I dont know how big the OpenWRT devellopers group is.

They are end-users, all of them.

They use a large range of hardware that mostly has its own unuseable
software.

e.g. dtag.de // t-online.de

they use a branded AVM router with outdated software and a backdoor
to remotely manage the box. I dont know if they really manage - but
I can see they have disabled port 8085 just in case.

AVM is as famous for routers in germany as Mircrosoft is for PCs.
I dont mean the pubo-coccygeus muscle :)

AVM software seems to be better but the brands see no maintainance.

Our gouvernement is very hot on talking about poisoning every router
and every PC to listen into our VPNs and local harddisks. So nobody
who has got a brain wants to rely on the original software.

I guess it is a good idea to get those end-users envolved.

Cheers
Peter and Karin

-- 
Peter and Karin Dambier
Cesidian Root - Radice Cesidiana
Rimbacher Strasse 16
D-69509 Moerlenbach-Bonsweiher
+49(6209)795-816 (Telekom)
+49(6252)750-308 (VoIP: sipgate.de)
mail: [email-masked]
mail: [email-masked]
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/
http://www.cesidianroot.com/

---

From: Jeroen Massar <[email-masked]>
Date: Thu, 20 Sep 2007 09:12:03 +0100

Keith Moore wrote:
> and without the PMTU reduction issues.

Exactly what I meant. The 'bilateral agreement' is the unknown magic
pixie dust though which should be automated and is the biggest problem.
For the rest it is indeed just automated "tunnels".

> And if the addresses used at the host are unique, it gets rid of many
> of the problems caused by overlapping use of RFC 1918 addresses in IPv4.
> There's still some issues related to traceability of traffic over the
> network, but maybe those are manageable.

The source and destination address are globally unique. As such you know
where the traffic comes from as all these prefixes are correctly
registered in whois. This means that an end-site organization might have
5 /48's in whois: one they use for "ID", this can be a special block
like ULA, PI or just a block they get from one of their upstream ISPs,
and maybe 4 from their upstream ISPs. All would be in whois, pointing at
least to the ISP responsible and maybe even to the org that is using it.
As long as uRPF is correctly enabled nothing will go through the DMZ
which is not from the ISP that actually is supposed to send data sourced
from that prefix. Traceability thus becomes easier as traffic has to be
sourced from the ISP it has to come from.

As mentioned above "PI" blocks can be used for this. As such
organizations who can convince all ISPs in the DFZ that they are
important enough to have their own routing slot can cough up the dough
and be there, others will just have to do with this mechanism to get around.

Greets,
 Jeroen

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 20 Sep 2007 14:28:58 +0200

> appear to be completely missing the point, but there is no reason  

[why ULA-C is not a problem]

I agree 100%

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 20 Sep 2007 14:22:31 +0200

Lda.com>
From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 20 Sep 2007 14:22:29 +0200
To: Stephen Sprunk <[email-masked]>
Cc: [email-masked], Noel Chiappa <[email-masked]>
Subject: Re: IPv6 will never fly: ARIN continues to kill it

On 19-sep-2007, at 16:40, Stephen Sprunk wrote:

[provider independent addresses]

> However, it is the only solution available today that the  
> operational folks consider viable.  The IETF promised something  
> different and has yet to deliver, so PI was passed and deployed.   
> If the IETF does eventually deliver something viable, the RIRs will  
> consider deprecating PI.

And that would be the same kind of consideration that has gone  
towards "deprecating" the holding of nearly 0.5% of the total IPv4  
address space by a single organization? Despite the fact that we're  
quickly running out of available IPv4 space and the number of  
organizations involved is less than 50, visible efforts have yet to  
materialize. So I doubt anything is going to happen once a few tens  
of thousands of organizations have cast their IPv6 PI addresses in  
stone. Those prefixes will be around for a _long_ time.

> Those who propose shim6 or similar solutions need to expect it'll  
> take another decade after the ink is dry for their solutions to be  
> considered viable

Curious how so many people know exactly that so many transitions will  
take a decade or more, without ANY precedents to base this on.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 20 Sep 2007 14:22:31 +0200

Lda.com>

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 20 Sep 2007 14:22:31 +0200

Lda.com>

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 20 Sep 2007 14:22:31 +0200

> tokens is a good way to go.

I don't think having a large set of source addresses with different  
reachability is a good thing, but it's likely unavoidable to have  
several.

If applications don't want to worry about addressing issues, the only  
solution is that applications don't get to see addresses in the first  
place. (The multi-address genie is out of the box regardless of  
anything else just by virtue of having an IPv4 and an IPv6 address.)  
The corollary being that protocols implemented inside applications  
must be address agnostic as well.

---

From: Keith Moore <[email-masked]>
Date: Thu, 20 Sep 2007 08:32:49 -0400

---

From: Keith Moore <[email-masked]>
Date: Thu, 20 Sep 2007 08:32:49 -0400

---

From: Keith Moore <[email-masked]>
Date: Thu, 20 Sep 2007 08:32:49 -0400

---

From: Keith Moore <[email-masked]>
Date: Thu, 20 Sep 2007 08:32:49 -0400

Iljitsch van Beijnum wrote:
> place.
If you can find a good way to let hosts and network stacks sort out
those addressing issues, then fewer applications will bother to manage
those addresses themselves.  But absent such a way to do that (and
trial-and-error is not a good way, nor is IPv6 "address selection") then
more applications will be forced to manage those addresses in order to
provide decent service to users.  Or to put it another way, as long as
an application can provide better service by explicitly managing
addresses than one that doesn't explicitly manage addresses, there will
be incentives for apps to explicitly manage addresses and many apps will
do so.

There's a whole separate issue in that networks trying to do filtering
on the basis of source and/or destination address hides policy from
applications.  So the application doesn't know whether it is violating
policy or routing around a failure of the network.  And realistically,
the answer is probably different for different applications.

Keith

<https://www1.ietf.org/mailman/listinfo/ietf>,
	<mailto:[email-masked]?subject=unsubscribe>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>,
	<mailto:[email-masked]?subject=subscribe>
Errors-To: [email-masked]

Iljitsch van Beijnum wrote:
> place.
If you can find a good way to let hosts and network stacks sort out
those addressing issues, then fewer applications will bother to manage
those addresses themselves.  But absent such a way to do that (and
trial-and-error is not a good way, nor is IPv6 "address selection") then
more applications will be forced to manage those addresses in order to
provide decent service to users.  Or to put it another way, as long as
an application can provide better service by explicitly managing
addresses than one that doesn't explicitly manage addresses, there will
be incentives for apps to explicitly manage addresses and many apps will
do so.

There's a whole separate issue in that networks trying to do filtering
on the basis of source and/or destination address hides policy from
applications.  So the application doesn't know whether it is violating
policy or routing around a failure of the network.  And realistically,
the answer is probably different for different applications.

Keith

<https://www1.ietf.org/mailman/listinfo/ietf>,
	<mailto:[email-masked]?subject=unsubscribe>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>,
	<mailto:[email-masked]?subject=subscribe>
Errors-To: [email-masked]

Iljitsch van Beijnum wrote:
> place.
If you can find a good way to let hosts and network stacks sort out
those addressing issues, then fewer applications will bother to manage
those addresses themselves.  But absent such a way to do that (and
trial-and-error is not a good way, nor is IPv6 "address selection") then
more applications will be forced to manage those addresses in order to
provide decent service to users.  Or to put it another way, as long as
an application can provide better service by explicitly managing
addresses than one that doesn't explicitly manage addresses, there will
be incentives for apps to explicitly manage addresses and many apps will
do so.

There's a whole separate issue in that networks trying to do filtering
on the basis of source and/or destination address hides policy from
applications.  So the application doesn't know whether it is violating
policy or routing around a failure of the network.  And realistically,
the answer is probably different for different applications.

Keith

<https://www1.ietf.org/mailman/listinfo/ietf>,
	<mailto:[email-masked]?subject=unsubscribe>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>,
	<mailto:[email-masked]?subject=subscribe>
Errors-To: [email-masked]

Iljitsch van Beijnum wrote:
> place.
If you can find a good way to let hosts and network stacks sort out
those addressing issues, then fewer applications will bother to manage
those addresses themselves.  But absent such a way to do that (and
trial-and-error is not a good way, nor is IPv6 "address selection") then
more applications will be forced to manage those addresses in order to
provide decent service to users.  Or to put it another way, as long as
an application can provide better service by explicitly managing
addresses than one that doesn't explicitly manage addresses, there will
be incentives for apps to explicitly manage addresses and many apps will
do so.

There's a whole separate issue in that networks trying to do filtering
on the basis of source and/or destination address hides policy from
applications.  So the application doesn't know whether it is violating
policy or routing around a failure of the network.  And realistically,
the answer is probably different for different applications.

Keith

---

From: Keith Moore <[email-masked]>
Date: Thu, 20 Sep 2007 08:38:24 -0400

> and maybe 4 from their upstream ISPs. 
I am fairly convinced, however, that the more address prefixes a site
has above some small number, the slower and less reliable applications
will be.

Keith

---

From: Keith Moore <[email-masked]>
Date: Thu, 20 Sep 2007 08:38:24 -0400

Keith

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 20 Sep 2007 14:41:23 +0200

> provide decent service to users.

Well, a start would be a "connectbyname()" API call that takes care  
of name-to-address mapping and trying different addresses until one  
works.

---

From: Keith Moore <[email-masked]>
Date: Thu, 20 Sep 2007 08:52:38 -0400

> Well, a start would be a "connectbyname()" API call that takes care of
> name-to-address mapping and trying different addresses until one works.
Most IPv6-capable apps seem to implement that logic now.  And in my
experience, it sucks.  Really hard.   The app can take a very long time
to establish a very poor connection.  The specific reason tends to be
that the destination and source both have IPv4 and IPv6 addresses, and
the IPv4 address works better than the IPv6 address (maybe because of
6to4 relay routers or whatnot), even though the v6 address is chosen
first.  But this is just an instance of the general case that some
source-destination address pairs work better than others.  Address
selection heuristics don't do a good job solving this problem - to solve
this problem the network actually needs to tell the host which
source-destination address pairs will work well.  (and that's pretty ugly)

So what you seem to be doing is asking application writers to accept
degraded performance and reliability in order to conform to some
arbitrary notion of purity.   I don't see it happening. 

On the other hand, if you make it such that application writers can get
good performance and reliability without messing with addresses, most
won't see a need to bother with the complexity.  But there will still be
corner cases that will.

Keith

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 20 Sep 2007 15:08:26 +0200

> to establish a very poor connection.

If you're going to establish a poor connection, at least do it  
fast.  :-)

> The specific reason tends to be
> first.

We can generalize this into: when you have a choice, you're going to  
make the wrong choice some of the time.

Downloading over IPv6 is still almost always slower than over IPv4,  
but for day-to-day stuff the performance difference isn't an issue  
with native IPv6 connectivity (for me). 6to4 is a crapshoot, it can  
be reasonable or it can completely fail, with everything in between.  
But it's never going to be better than native IPv4, obviously.

> But this is just an instance of the general case that some

I agree that this is an important issue, but I fail to see how this  
relates to applications knowing about addresses, unless applications  
are going to do their own performance testing, which I don't recommend.

> arbitrary notion of purity.   I don't see it happening.

Multiple addresses are a reality, not just because the IPv6 specs say  
so, but also because lots of hosts are going to have at least one  
IPv4 address and at least one IPv6 address. Has nothing to do with  
purity.

> won't see a need to bother with the complexity.  But there will  

As I said, a good start would be that API because once applications  
use it, people working on better address selection etc have a place  
to insert their stuff and improve performance of real applications  
without having to rewrite the application.

---

From: <[email-masked]>
Date: Thu, 20 Sep 2007 14:31:20 +0100

> Downloading over IPv6 is still almost always slower than over 
> IPv4, but for day-to-day stuff the performance difference 
> isn't an issue with native IPv6 connectivity (for me). 6to4 
> is a crapshoot, it can be reasonable or it can completely 
> fail, with everything in between.  

That will improve as more people set up 6to4 relay services
http://www.getipv6.info/index.php/First_Steps_for_ISPs#Setup_A_6to4_Rela
y

> But it's never going to be better than native IPv4, obviously.

Not so. Native IPv4 will route packets by choosing the best path.
Part of that path decision will be made via BGP which allows
network administrators to remove certain paths from the list
of possibilities. When a 6to4 relay is used, the destination
IPv4 address is that of the tunnel endpoint, not the final
destination. It is entirely possible that a tunnel endpoint
may take the packets into an AS which would not otherwise be
used and which IS a better path than would be chosen by pure
IPv4 routing. Back in the 1990s some shrewd American ISPs used
this fact to get free transit from certain ASNs because the
traffic to a tunnel endpoint qualified under the peering agreement.

--Michael Dillon

---

From: Paul Vixie <[email-masked]>
Date: Thu, 20 Sep 2007 13:59:03 +0000

> As mentioned above "PI" blocks can be used for this. As such organizations
> who can convince all ISPs in the DFZ that they are important enough to have
> their own routing slot can cough up the dough and be there, others will just
> have to do with this mechanism to get around.

by what method do you expect the dfz to start resisting new routes unless new
fees are paid?  there is no historical precedent for such fees, nor for a
transition from no-fees to fees where all decisionmakers are third parties.

absent such a method, the network operators who dominate the bottom-up RIR
policy process are almost certainly going to make PI hard to qualify for.

which is why i'm asking for ULA-G.

---

From: Patrick Vande Walle <[email-masked]>
Date: Thu, 20 Sep 2007 16:24:58 +0200

As the original blog poster, let me answer and expand a bit:

Jeroen Massar wrote:
>From those one billion Internet users, there are several millions IT
professionals who do not participate in the IETF work either because
they are not inclined to, or because their  employer does not see which
return such time investment would bring to the company. They provide
services to millions of end users and they are confronted on a daily
basis with issues that could be addressed by enhancing or drafting new
standards.  These people have the knowledge. They are not "hobbyists".
Over the last ten years, I explained a zillion times to my management,
workmates, etc. why e-mail addresses cannot contain accented characters,
only to be asked when the IT department of the organization is going to
"fix it". This is the archetypical example of an issue that has been
known since the days of RFC821/822. Yet, work to address this has only
started a year ago, although I am conscious there were some intermediate
step needed, like Unicode.

Please don't ask me to complain to my software vendor. At best, I am
being told that their software is standards-compliant. So, if the end
user/customer cannot get the supplier to proactively propose new
standards, there has to be a way to escalate the issue to whatever body
that can solve it.

My proposal for the IETF would be to ask the actual users, large and
small, through different mechanisms to be defined, what are the issues
that limit their use of the Internet, see what is relevant to the IETF
work and assign priorities to the development of new standards.

As for the average end user: I am sure that my grandfather would have
liked to be able to type an e-mail, including recipient names, with
accented characters.  He was already able to do so for letters and
envelopes on his typing machine in the 1920's.  My neighbour may not
know what an IPv6 /64 is. He may however understand that he will have a
lot of home devices connected to the Internet on his home network in a
few years from now, and this may require some segmentation, which a /64
does not provide. Actually, I hope my neighbour will never have to know
about these details, and that his home router will figure this out
automatically.

Patrick Vande Walle

-- 
Patrick Vande Walle
Check my blog at http://patrick.vande-walle.eu
Jabber me at [email-masked]

---

From: Christian Huitema <[email-masked]>
Date: Thu, 20 Sep 2007 07:32:32 -0700

> of name-to-address mapping and trying different addresses until one

Something like WSAConnectByName?

>From http://msdn2.microsoft.com/en-us/library/ms741557.aspx: "The WSAConnectByName function establishes a connection to a specified host and port. This function is provided to allow a quick connection to a network endpoint given a host name and port. This function supports both IPv4 and IPv6 addresses."

-- Christian Huitema

---

From: Keith Moore <[email-masked]>
Date: Thu, 20 Sep 2007 10:52:50 -0400

> If you're going to establish a poor connection, at least do it fast.  :-)
And then wait for it to timeout.
> with native IPv6 connectivity (for me). 6to4 is a crapshoot, it can be
> reasonable or it can completely fail, with everything in between. But
> it's never going to be better than native IPv4, obviously.
No, not obviously - because if the application has a need to do address
referral then there are conditions in which the 6to4 address will work
better.
> are going to do their own performance testing, which I don't recommend.
p2p applications are doing this already.  Sure it's ugly, but they still
do it, because they have to.  Applications writers would rather not
bother with it.  But until the network again does a good job at
providing good performance while hiding the complexity of routing from
applications, the applications will be forced to bother with it.   (The
old idea that the network provided "best effort" packet delivery service
meant that the applications really didn't have a way to improve on what
the network was doing, so they didn't bother.   But in the new world of
lots of source and destination addresses, and arbitrary filtering (from
the application's view) the network is effectively no longer responsible
for providing "best effort" service.  As a result, the layering breaks
down.)
> so, but also because lots of hosts are going to have at least one IPv4
> address and at least one IPv6 address. Has nothing to do with purity.
Yep, and there are lots of other reasons why multiple addresses will be
there - mobility, multiple active network interfaces, encrypted tunnels,
etc.   So there's going to continue to be a need for some applications
to deal with this explicitly.

The notion of purity I was referring to was the one that applications
should only deal with names and not with addresses.
> use it, people working on better address selection etc have a place to
> insert their stuff and improve performance of real applications
I spent a fair amount of time trying to come up with an API that would
let applications push this decision-making to a lower layer while
allowing that lower layer to make those decisions effectively based on
the needs of that particular application.  That API ended up looking
fairly complex.  There are lots of factors that influence address selection.

Keith

---

From: <[email-masked]>
Date: Thu, 20 Sep 2007 16:13:01 +0100

> Over the last ten years, I explained a zillion times to my 
> management, workmates, etc. why e-mail addresses cannot 
> contain accented characters, only to be asked when the IT 
> department of the organization is going to "fix it". This is 
> the archetypical example of an issue that has been known 
> since the days of RFC821/822. Yet, work to address this has 
> only started a year ago, although I am conscious there were 
> some intermediate step needed, like Unicode.

For this to work, we need a way to display that address on
devices which do not have the complete set of Unicode glyphs
installed. And we also need a way to display a representation
of the address that can be used to unambiguously input the
address on a device which does not understand the full set
of Unicode glyphs.

This was discussed a couple of days ago in this message
http://www1.ietf.org/mail-archive/web/ietf/current/msg47925.html
regarding deprecating RFC 1345 because it is the wrong solution
to the problem.

In fact, it may be necessary to attach a language tag (defined 
in RFC 4646 and 4647) to these addresses in order to make this
fully possible. For instance, there is a Norwegian mans' name
which is usually written Hakon in English. In Norwegian, the 
letter a is written with a small ring attached to the top. This
ring represents that the name is pronounced more like Hokon than
Hakon. Nevertheless, it is standard for people to us a double a
to represent this glyph (a-ring) when writing Norwegian with
devices which do not have the a-ring glyph. But Haakon is even
more misleading to English eyes.

In order for an email display and entry device to fully make sense
of addresses which contain a glyph not available on the device,
it may be necessary to know both the language tag of the device
user, as well as the language tag of the address.

I'm sure that many people are working on this problem, but most
of this work is happening outside of the IETF. Perhaps even in 
commercial ventures like Mozilla's new email company,
http://www.mozilla.com/en-US/press/mozilla-2007-09-17.html

--Michael Dillon

---

From: Peter Dambier <[email-masked]>
Date: Thu, 20 Sep 2007 18:29:40 +0200

Daniel Senie wrote:
> At 04:18 AM 9/20/2007, you wrote:
> 
>> Interesting discussion.
>>
> End users? Interesting. Though I've been in the software, systems and 
> networking business for 25 years, I don't know what "TORify" means. Step 
> back and look around. Getting more of us geeks providing "end user" 
> feedback is not functional. That's how we get to having cameras, cell 
> phones and most other electronics with user interfaces that non-geeks 
> can't understand.

TOR is "The Onion Router".

The people are afraid of the gouvernement spying on them, that is why
everybody is talking about anonymisation tools. Some people do provide
them for free.

> 
> We are not good models of the term "end user."
> 
> 

I guess you are right :)

Cheers
Peter and Karin

---

From: Peter Dambier <[email-masked]>
Date: Thu, 20 Sep 2007 18:25:34 +0200

I guess you are right :)

Cheers
Peter and Karin

-- 
Peter and Karin Dambier
Cesidian Root - Radice Cesidiana
Rimbacher Strasse 16
D-69509 Moerlenbach-Bonsweiher
+49(6209)795-816 (Telekom)
+49(6252)750-308 (VoIP: sipgate.de)
mail: [email-masked]
mailFrom [email-masked] Thu Sep 20 12:34:53 2007
Date: Thu, 20 Sep 2007 18:29:40 +0200
From: Peter Dambier <[email-masked]>
Organization: Peter and Karin Dambier
To: [email-masked]
Subject: Re: Representation of end-users at the IETF (Was: mini-cores (was
 Re:	ULA-C)
Reply-To: [email-masked]

I guess you are right :)

Cheers
Peter and Karin

___: [email-masked]
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/
http://www.cesidianroot.com/

____________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Peter Dambier <[email-masked]>
Date: Thu, 20 Sep 2007 18:25:34 +0200

I guess you are right :)

Cheers
Peter and Karin

---

From: Peter Dambier <[email-masked]>
Date: Thu, 20 Sep 2007 18:47:51 +0200

Sorry for the double post.

My mailer either sends it double - or nothing at all :(

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 20 Sep 2007 18:51:17 +0200

On 20-sep-2007, at 16:52, Keith Moore wrote:

>> 6to4 is a crapshoot, it can be

> referral then there are conditions in which the 6to4 address will work

I was talking about performance. I guess even there there are a few  
cases where 6to4 can do better than the IPv4 it's carried over, but  
that should be rare.

> p2p applications are doing this already.

Do you mean BitTorrent? Those applications don't really test  
performance, but simply use different addresses concurrently. Which  
is an excellent way to make the question of which address performs  
better moot, by the way.

> fairly complex.  There are lots of factors that influence address  

Yes, communicating application needs back and forth would be tricky.  
For instance, suppose I have two links: one is 2 Mbps ADSL. This is  
not so bad that an application can't run, but if my other link is  
1000 Mbps, then the application would probably want to use that link.  
But the application doesn't know if that's the case, it could also be  
a GPRS link with enormous latency and virtually no bandwidth. So what  
does the application say?

---

From: Peter Dambier <[email-masked]>
Date: Thu, 20 Sep 2007 18:47:51 +0200

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 20 Sep 2007 18:51:17 +0200

---

From: Marc Manthey <[email-masked]>
Date: Thu, 20 Sep 2007 18:58:42 +0200

On Sep 20, 2007, at 6:29 PM, Peter Dambier wrote:
>> End users? Interesting. Though I've been in the software, systems  
>> and networking business for 25 years, I don't know what "TORify"  
>> means. Step back and look around. Getting more of us geeks  
>> providing "end user" feedback is not functional. That's how we get  
>> to having cameras, cell phones and most other electronics with  
>> user interfaces that non-geeks can't understand.
>

hello  peter and Daniel,  all

i am using  openwrt / White russian for my test enviroment, i guess  
you mean this <https://www.agol.dk/elgaard/torap/>

there is an impressive list of  software  for openwrt <http:// 
downloads.openwrt.org/backports/0.9/>

greetings from an enduser;)

marcM.

--
there's no place like 127.0.0.1
until we found ::1 -- which is even bigger

web: http://www.let.de

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 20 Sep 2007 10:26:21 -0700

>work and assign priorities to the development of new standards.

Why the IETF? Why not ISOC, an organization that has expertise and 
experience is asking such questions? ISOC already has local chapters 
throughout the world, ISOC has a friendly membership policy, and ISOC 
has good relations with the IETF for discussing proposed improvements 
to the Internet.

--Paul Hoffman, Director
--VPN Consortium

---

From: "Stephen Sprunk" <[email-masked]>
Date: Thu, 20 Sep 2007 13:46:43 -0500

Thus spake "Paul Vixie" <[email-masked]>
>> organizations

In the ARIN region, one can qualify for PI today with as few as 256 hosts, 
and there was a recent proposal that would have indirectly dropped that to 
64 hosts.  I cannot justify calling that "hard"; it's arguably "too easy". 
However, the fact is that small PIv4 assignments have had virtually no 
uptake -- a few hundred /21-22 blocks assigned according to ARIN staff 
recently.  The DFZ has not exploded, and in fact it's growing slower than 
Moore's Law.

If you're worried about the DFZ and/or exhaustion, go look at the few dozen 
big ISPs that are putting hundreds to thousands of routes each in the DFZ 
and consuming over 80% of the RIR IP space.  The tiny PI players are a 
negligible factor compared to the massive deaggregation done by the bigger 
players due to some combination of TE and incompetence.

S

---

From: Paul Vixie <[email-masked]>
Date: Thu, 20 Sep 2007 19:02:48 +0000

> 64 hosts.  I cannot justify calling that "hard"; it's arguably "too easy".

would it scale?  (would it be allowed to try?)

i'm not talking about the current situation, which is a social experiment.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 20 Sep 2007 15:15:56 -0400

> that statement.  Your second statement:

 From my point of view, ULA-C differs from 4193 because I presume a ULA-C 
will give me whois and reverse DNS.

I've been told that sixxs.net is doing whois, but I have to know to ask
whois.sixxs.net for the information.
Delegating c.f.ip6.arpa to sixxs.net would also be required for me to take 
4193 seriously. (And d.f.ip6.arpa..)

I am very happy to use a ULA for my needs, and a PA for the part of my 
network that needs to talk to outside my AS.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 20 Sep 2007 15:15:56 -0400

---

From: Keith Moore <[email-masked]>
Date: Thu, 20 Sep 2007 15:40:42 -0400

>>> 6to4 is a crapshoot, it can be reasonable or it can completely fail,
>>> with everything in between. But it's never going to be better than
>>> native IPv4, obviously.
>> No, not obviously - because if the application has a need to do
>> address referral then there are conditions in which the 6to4 address
>> will work better.
>
More common than you might think, especially given that native IPv4 is
often subject to traffic filters that might not apply to 6to4.

> performance, but simply use different addresses concurrently. Which is
> an excellent way to make the question of which address performs better
> moot, by the way.
The applications that do that still have to deal with addresses
explicitly.  p2p transfer of large file is sort of a special case since
you can generally afford to spend some time learning which paths are
more efficient.
>> I spent a fair amount of time trying to come up with an API that
>> would let applications push this decision-making to a lower layer
>> while allowing that lower layer to make those decisions effectively
>> based on the needs of that particular application.  That API ended up
>> looking fairly complex.  There are lots of factors that influence
>> address selection.
>
> not so bad that an application can't run, but if my other link is 1000
> Mbps, then the application would probably want to use that link. But
> the application doesn't know if that's the case, it could also be a
> GPRS link with enormous latency and virtually no bandwidth. So what
The application says something like "I need a minimum of X Mb/s
bandwidth" (which implies, e.g. don't use any interface that can't
provide that)  or "I don't need much bandwidth but I do need a
connection that's going to stay up for awhile" (e.g. use the GPRS
interface or maybe the mobile IP in-care-of address) or "I need as much
bandwidth as possible but I don't expect the connection to need to stay
up very long".  (use the fastest path available or maybe even more than
one path concurrently) or "I need the best latency I can get but the
amount of data transferred will be small and the duration will be short".

Keith

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 20 Sep 2007 22:08:31 +0200

On Thu, Sep 20, 2007 at 04:13:01PM +0100,
 [email-masked] <[email-masked]> wrote 
 a message of 49 lines which said:

> In fact, it may be necessary to attach a language tag (defined in
> RFC 4646 and 4647) to these addresses in order to make this fully
> possible.

That would be a very bad idea. Email deals with scripts, not with
languages. What language should be attached to my name? (I'm french
but my name is german.) And to coca-cola.com?

> I'm sure that many people are working on this problem,

Sure, specially in the Far East, demos of I18N software for email are
common but all use non-standard tricks, they do not interoperate and
they do not fallback gracefully when encountering an old email
gateway.

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 20 Sep 2007 13:40:15 -0700

Please, folks. If you think that a technical issue should be being 
addressed by the IETF, first do a bit of research. In this case, that 
research would show that there is already a Working Group and lots of 
drafts on the topics.

<http://www.ietf.org/html.charters/eai-charter.html>

--Paul Hoffman, Director
--VPN Consortium

---

From: Peter Dambier <[email-masked]>
Date: Thu, 20 Sep 2007 23:31:41 +0200

How about

http://xn--8pru44h.xn--55qx5d/

and their email can be found:

; <<>> DiG 9.4.0b4 <<>> -t any xn--8pru44h.xn--55qx5d @ns5.ce.net.cn.
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59227
;; flags: qr aa rd; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;xn--8pru44h.xn--55qx5d.                IN      ANY

;; ANSWER SECTION:
xn--8pru44h.xn--55qx5d. 1800    IN      A       210.51.169.151
xn--8pru44h.xn--55qx5d. 1800    IN      NS      ns5.ce.net.cn.
xn--8pru44h.xn--55qx5d. 1800    IN      MX      10 mail.xn--8pRu44H.xn--55Qx5D.
xn--8pru44h.xn--55qx5d. 1800    IN      SOA     ns5.ce.net.cn. tech.ce.net.cn. 2004072009 3600 900 1209600 1800

;; ADDITIONAL SECTION:
mail.xn--8pRu44H.xn--55Qx5D. 1800 IN    A       211.157.122.194

;; Query time: 405 msec
;; SERVER: 210.51.171.200#53(210.51.171.200)
;; WHEN: Thu Sep 20 23:18:00 2007
;; MSG SIZE  rcvd: 196

I remember exchanging emails with them at least once.

Standard Thunderbird, Linux.
Mailer exim 4.0
Bind 9.4.0

I remember it worked with djbdns too.

No, I did not have a language tag.

There were no tricks besides using the Cesidian Root for DNS.
I guess the chinese used their native root.

Kind regards
Peter and Karin

---

From: "Stephen Sprunk" <[email-masked]>
Date: Thu, 20 Sep 2007 21:53:57 -0500

Thus spake "Keith Moore" <[email-masked]>
>> Well, a start would be a "connectbyname()" API call that takes
>> care of name-to-address mapping and trying different
>> addresses until one works.
>
> Most IPv6-capable apps seem to implement that logic now.  And
> in my experience, it sucks.  Really hard.   The app can take a
> very long time to establish a very poor connection.  The specific
> reason tends to be that the destination and source both have IPv4
> and IPv6 addresses, and the IPv4 address works better than the
> IPv6 address (maybe because of 6to4 relay routers or whatnot),
> even though the v6 address is chosen first.

Don't forget that you may have a half-dozen or more IPv6 PA addresses that 
_all_ have to be tried before the host is going to give up and try the v4 
address(es).  ULAs and LLAs also fit in there somewhere, as do 6to4 
addresses, Teredo addresses, VPN connections, etc.  Worse, the other host 
has just as many addresses as you do, with the same variable connectivity 
for each.  You can _easily_ end up with 100+ combinations to probe.

Murphy's Law says that the only address pair that works will be the last one 
that your "address selection" algorithm determines, no matter what algorithm 
you pick.  If you fix the algorithm, fate will respond by changing 
reachability so that the new "last" pair to probe is again the only one that 
works.

> source-destination address pairs work better than others.
> Address selection heuristics don't do a good job solving this
> problem - to solve this problem the network actually needs to tell
> the host which source-destination address pairs will work well.
> (and that's pretty ugly)

Yes, it's ugly, and it's not the only solution.  Another is for the client 
to initiate connections from every possible source address to every possible 
destination address at the same time, and for the transport protocol to 
support adding and removing L3 addresses from the connection over its 
lifetime as each host gains/loses prefixes.  Good luck deciding which of the 
N*M paths to send payload packets over for optimal throughput, latency, 
reliability, and cost (among which the stack will likely have no indication 
of prioritization from the app).  And, of course, that'll entail a 
substantial rework of TCP and most TCP stacks, which means it's at least a 
decade away.  What are we supposed to do until then?

S

---

From: Greg Skinner <[email-masked]>
Date: Fri, 21 Sep 2007 04:13:17 +0000

On Wed, Sep 19, 2007 at 12:08:38PM -0400, Keith Moore wrote:
> Paul Vixie wrote:
> > yes, but do you think that was because that ietf was powerless to
> > stop [NAT], or because that ietf was willing to let consenting
> > adults try out new ideas?  i was there, and from what i saw, it was
> > the former.
> >   

FWIW, I think NAT would have happened, IETF or no.  There were people
who needed a solution, and had the money to pay for it, and there were
people who could provide the solution, and were willing to do the work.
It raises the question of whether there are circumstances where it's
reasonable to bend the end-to-end principle, such as when there is a
large "user" community that wants inexpensive Internet access (but is
willing to live without IP access).

> think that NAPTs were initially seen as the normal case.

I remember such arguments.  I also remember an argument that NATs were
being marketed as security devices, when in fact they did not provide
the actual level of security implied.  RFC 3724 bears this out.

> analysis.  This is something we need to change in our culture.

Based on some recent experiences, this type of analysis is not as
valued in the industry as it used to be.  It's much more valued to be
a crack programmer; someone who can rapidly deploy something that can
be quickly brought to market.  At least in the current economic
climate, I don't think there is much that can be done to change this.
Another issue is that the networking industry in general is losing
people to other disciplines, such as gaming, virtualization, and
Internet search, not to mention careers outside of the computer
industry.

--gregbo

---

From: Keith Moore <[email-masked]>
Date: Fri, 21 Sep 2007 01:32:49 -0400

> people who could provide the solution, and were willing to do the work.
NAT would certainly have existed.  Whether it would have been widely
adopted in the form that it did, had IETF acted differently is another
question.  Certainly a quicker development of IPng (and perhaps,
development of IPng along somewhat different lines than IPv6) might have
helped, but it's hard to see how that could have happened.   The growth
rate of IPv4 both prompted the need for IPng and hindered its
standardization and deployment.  Second-system effect played a role also. 
> willing to live without IP access).
One problem with the "end to end principle" is that a lot of people cite
it as if it were a religious tenet (whether they're for or against it). 
People need to look past the "principle" and look at the reasoning that
led to the "principle", along with the actual effects of the violation
of that principle being considered.  That reveals why the principle
makes sense as a general rule and also whether violating it in some
specific way is a horrible idea or only a dubious one.
>>> among endpoints, either for secFrom [email-masked] Fri Sep 21 01:46:51 2007
Date: Fri, 21 Sep 2007 01:32:49 -0400
From: Keith Moore <[email-masked]>
To: Greg Skinner <[email-masked]>
OpenPGP: id=E1473978
Cc: 'IETF Discussion' <[email-masked]>
Subject: Re: ideas getting shot down

> people who could provide the solution, and were willing to do the work.
NAT would certainly have existed.  Whether it would have been widely
adopted in the form that it did, had IETF acted differently is another
question.  Certainly a quicker development of IPng (and perhaps,
development of IPng along somewhat different lines than IPv6) might have
helped, but it's hard to see how that could have happened.   The growth
rate of IPv4 both prompted the need for IPng and hindered its
standardization and deployment.  Second-system effect played a role also. 
> willing to live without IP access).
One problem with the "end to end principle" is that a lot of people cite
it as if it were a religious tenet (whether they're for or against it). 
People need to look past the "principle" and look at the reasoning that
led to the "principle", along with the actual effects of the violation
of that principle being considered.  That reveals why the principle
makes sense as a general rule and also whether violating it in some
specific way is a horrible idea or only a dubious one.
> the actual level of security implied.  RFC 3724 bears this out.
NAPTs were (misleadingly) marketed as security devices to consumers. 
But we were concerned about NATs in general, and at the time did not
make the generalization that all or most NATs were NAPTs.
> be quickly brought to market.
IETF cannot do its job properly if it is a slave to "the industry" and
its current idea of market conditions.  The Internet is not a market
fad.  It's a lot more like a global public works project that will have
effects lasting for decades (at least) which will affect everyone on the
planet.  It is absolutely necessary to pay careful attention to the long
term effects of its design decisions, and this cannot be done by people
who feel pressure to put something on the market in six months or a year.

At the same time, IETF needs to understand that optimizing for
deployability first and scalability second often succeeds whereas the
reverse often fails.  We need to understand how to design protocols that
can be deployed quickly and yet be upgraded gracefully as the real
requirements for long-term widespread use of the protocols  become
apparent. 

Keith

---

From: Keith Moore <[email-masked]>
Date: Fri, 21 Sep 2007 02:00:39 -0400

> Yes, it's ugly, and it's not the only solution.  Another is for the
> client to initiate connections from every possible source address to
> every possible destination address at the same time, and for the
> transport protocol to support adding and removing L3 addresses from
> the connection over its lifetime as each host gains/loses prefixes. 
> Good luck deciding which of the N*M paths to send payload packets over
> for optimal throughput, latency, reliability, and cost (among which
> the stack will likely have no indication of prioritization from the
> app).  And, of course, that'll entail a substantial rework of TCP and
> most TCP stacks, which means it's at least a decade away.  What are we
> supposed to do until then?
for now, as best as I can tell:

- use PI address space if you can get it, but at any rate design your
IPv6 network to support multiple prefixes and renumbering.  this
includes routing, security, network management, the whole ball o' wax.

- periodically test renumbering small portions of your internal network
(rotating through the different portions) to identify sources of
disruption.    start with less critical portions and gain experience
with them, work up to more critical portions as you develop the tools
and identify which hosts, routers, firewalls, ALGs, proxies, traffic
monitors, applications, etc. need to be fixed.

- if you can't get PI space and need to multihome with different
addresses, provision your external connections so that both all address
prefixes have approximately equal connectivity and equal reliability. in
other words, it shouldn't matter which source or destination address an
application picks, they should all give good performance under most
conditions.

- make your IPv6 connectivity at least as good (for IPv6 hosts) as your
IPv4 connectivity, so that apps that pick IPv6 over IPv4 won't be penalized

- make your IPv6 security at least as robust as your IPv4 security, so
that IPv6 doesn't get the reputation as an end-run around your security.

- start out by assuming that IPv6 and IPv4 have the same filtering
policy for each service.  then on a case-by-case basis assess whether
they need to be different, being aware that different policies can
confuse applications which are IP-version agile.

- if you have a need to make some hosts globally accessible via IPv6,
give those hosts 6to4 prefixes in addition to native prefixes so that
they can get connectivity from other 6to4 hosts without having to go
through relay routers.

- avoid ULAs.   you might find that you absolutely have to have them in
a few cases for use by apps that simply cannot survive renumbering.  but
those should be treated as exceptional cases and indications of a larger
problem, and the ULA should be treated as a temporary fix rather than a
permanent one.

---

From: Patrick Vande Walle <[email-masked]>
Date: Fri, 21 Sep 2007 12:34:57 +0200

Paul Hoffman wrote:

> has good relations with the IETF for discussing proposed improvements to
> the Internet.

I founded an ISOC chapter some years ago among others to see how users
could provide input to the standards development process. However, there
is no mechanism to consult, collect and present such information in an
organized way.

You could say that, as an ISOC trustee, I would need to submit a
proposal to the board, and this is exactly what I intend to do. Keep in
mind though that those volunteers in chapters may expect that some
consideration and feedback is being given to their (sometimes non
technical) comments. If they are by default considered irrelevant,
hobbyist rubbish, this may kill the process in the egg.

Part of the goal of this discussion, for me, is to see how the IETF
community welcomes such a proposal. If I get the impression that it is
not supported, I won't spend more time on it.

Patrick

.

---

From: Patrick Vande Walle <[email-masked]>
Date: Fri, 21 Sep 2007 12:34:57 +0200

Patrick

.

---

From: "Stephen Sprunk" <[email-masked]>
Date: Fri, 21 Sep 2007 09:55:39 -0500

> deployability first and scalability second often succeeds whereas
> the reverse often fails.  We need to understand how to design
> protocols that can be deployed quickly and yet be upgraded
> gracefully as the real requirements for long-term widespread use
> of the protocols become apparent.

This is the true failing of the IPng effort: all the attention was focused 
on the end result, with virtually no effort towards a viable transition 
model.  A contributing factor was that the IETF designed IPng in a vacuum 
and tossed it over the wall to operators, and completely ignored (and is 
still ignoring) feedback on why people aren't deploying it.

A large part of this hubris comes from the success of IPv4 itself.  There 
were dozens of different L3 protocols in use in the 80s and early 90s, so 
operators had little problem adding yet another one to their networks -- and 
IPv4 was so much better than the others that the remainder faded away rather 
quickly in the mid 90s.  It seems to have been assumed that operators would 
have no problem going back to the dual-stack model to get IPv6 and would 
drop IPv4 relatively quickly.  However, since v6 isn't much better than v4 
(arguably worse, if one considers the number of hosts reachable, equipment 
replacement, staff retraining, etc.), it just hasn't happened.  Add to that 
a transition model that _requires_ that every host be dual-stacked before 
the first v6-only node appears and you've got a horrible chicken-and-egg 
problem where nobody has any incentive to create a critical mass of 
dual-stacked hosts.  Also add in how long it took MS to ship an OS with v6 
on by default; that should have happened by 1998 or 2000 -- not 2007.

NAT-PT was a reasonable solution to this (with a few tweaks), since it could 
make hosts _appear_ to be dual-stacked with little effort, but it offended 
the purists and was killed despite there being nothing to replace it.

S

---

From: Keith Moore <[email-masked]>
Date: Fri, 21 Sep 2007 11:21:12 -0400

Stephen Sprunk wrote:
>> reverse often fails.  We need to understand how to design protocols
>> that can be deployed quickly and yet be upgraded gracefully as the
>> real requirements for long-term widespread use of the protocols
>> become apparent.
>
> This is the true failing of the IPng effort: all the attention was
> focused on the end result, with virtually no effort towards a viable
> transition model.  
That's actually not true; at least one proposal that got some traction
was very focused on a viable transition model.  But more people were
concerned about the end result.  And I do think this is a kind of
second-system effect.
> A contributing factor was that the IETF designed IPng in a vacuum and
> tossed it over the wall to operators, and completely ignored (and is
To me it looks like operational issues drove all of the design changes
between v4 and v6.   But the operational issues were ISP operational
issues, not operational issues in enterprise networks.

But it's almost a given that there would be a long feedback path.  The
users will be the last to understand and react to any major
architectural change.  It's hard for them to really know what they're
getting and how to deal with it until it actually ships in products that
they're using.   Also, users are very diverse, and the way the network
is used is constantly changing, so it's hard to anticipate what users
will need, say, 10 years hence when the stuff finally gets deployed.
> Also add in how long it took MS to ship an OS with v6 on by default;
> that should have happened by 1998 or 2000 -- not 2007.
Well, it took them until 1995 to ship IPv4, and even then it wasn't "on
by default".  :)
> NAT-PT was a reasonable solution to this (with a few tweaks), since it
> could make hosts _appear_ to be dual-stacked with little effort, but
> it offended the purists and was killed despite there being nothing to
> replace it.
No, NAT-PT was not a reasonable solution, because it would have crippled
the IPv6 network even moreso than the NATted IPv4 network, in addition
to  trashing DNS, and without providing any incentive to move to a
native (non-NATted) IPv6 network.

Keith

---

From: <[email-masked]>
Date: Fri, 21 Sep 2007 16:40:41 +0100

> Add to that a transition model that 
> _requires_ that every host be dual-stacked before the first 
> v6-only node appears and you've got a horrible 
> chicken-and-egg problem where nobody has any incentive to 
> create a critical mass of dual-stacked hosts. 

If that was true, you'd be right, but it's not, therefore
you are wrong.

>From an operator viewpoint, IPv6 can be deployed without dual-stack
either by using 6PE on an MPLS core, or by building an IPv6 overlay
core using tunnels. Neither requires dual-stack everywhere, in fact
both models of deployment are desirable specifically because they
focus the change on just one part of the network.

> NAT-PT was a reasonable solution to this (with a few tweaks), 
> since it could make hosts _appear_ to be dual-stacked with 
> little effort, but it offended the purists and was killed 
> despite there being nothing to replace it.

What's this about NAT-PT being killed? I still see vendor literature
which mentions NAT-PT support. If it works, and it is implemented,
then people will use it.

Same thing goes for Application Layer Gateways, i.e. proxies.

I don't think any network operator is in the business of being an
IETF purist. It is desirable that hardware and software adheres to
standards but it is more important for them to *WORK*!!! And if there
is a standards vacuum, that will not stop deployment.

--Michael Dillon

---

From: <[email-masked]>
Date: Fri, 21 Sep 2007 16:40:41 +0100

--Michael Dillon

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 21 Sep 2007 08:31:56 -0700

We are all end-users, the question is whether the work here should be more responsive to the needs of typical end users.

We have interminable discussions premised on the bizare assumption that the typical end user cares more about whether he has a /48 or /56 than whether his or her network works reliably, without fuss, supports the applications they want to use and does not make them artificially dependent on a particular service provider.

Equally you can be sure that in any discussion of a proposed change to the Internet that there will be someone who will come up with the equivalent of 'but if we phase out use of UUCP that will cause systems which people rely on in remote parts of Africa to fail', and you can be sure that the person raising the objection 1) has never been to Africa, 2) has zero personal contact with anyone in Africa who has the issue he claims to be critical, 3) is entirely ignorant of the constraints under which Internet management in Africa operates, 4) has some 30 year old UUCP installation that they want to keep running for personal reasons.

We used to have the same issue with accessibility. Some people would bring up accessibility in a similarly insincere fashion. By this I mean using accessibility as a debating maneuver without any real interest in meeting needs of disabled persons. 

That is rather harder today, first there are quite a few people in the IETF who have direct experience in those areas, either as a user or developer of accessibility technologies, second there is a whole accessibility effort in W3C that focuses on the issues directly.

So when folk object that using PKIX logotypes in certificates rasies accessibility issues with blind and partially sighted people I have a lot of resources I can draw on. I talk to the people concerned, take their input into account and come up with a (slightly) revised proposal.

I don't think it is actually very difficult to become an advocate for the ordinary user. Just decide to become 100% intolerant of network administrivia. When friends or relatives ask for help setting up their systems ask why the assistance is needed and how the network could be changed to make that help unnecessary.

Sit in on some usability tests for real products. It is quite interesting watching someone who claims tho be proficient in the use of certain network infrastructures actually using them to achieve what should be routine tasks. 

The User Interface itself may be out of scope for a protocol but the need for user interaction is not. In particular a protocol must provide the information necessary for the UI to function. A very large number of UI issues are really caused by poor architecture, lack of though given to error conditions is a major cause. In PKIX the protocols make the bizare assumption that every Internet user wants to become a trust engineer. This is better than the original assumption that PEM was based on but still too far away from the idea that everyone wants to have the choice of who they delegate their trust management tasks to.

> -----Original Message-----
> From: Jeroen Massar [mailto:[email-masked]] 
> Sent: Wednesday, September 19, 2007 6:30 PM
> To: Stephane Bortzmeyer
> Cc: [email-masked]
> Subject: Re: Representation of end-users at the IETF (Was: 
> mini-cores (was Re: ULA-C)
> 
> > On Wed, Sep 19, 2007 at 12:50:44AM +0000,  Paul Vixie 
> <[email-masked]> 
> > wrote  a message of 32 lines which said:
> > 
> That we might have quite a bit more knowledge on how things 
> work and that we might have some connections to people so 
> that we can arrange things, is nothing of an advantage over 
> people who are not technically inclined (or how do you put 
> that nicely ;)
> 
> The point is that those people don't know better and as such 
> they also don't know what is possible and what they are missing.
> 
> Eg, if you tell somebody "oh but I have a /27 IPv4 and a /48 
> IPv6 at home and I can access all my computers from the 
> Internet wherever I am", they will be going "and? why would I 
> need that". The typical lay-man end-user really couldn't care 
> less, as long as their stuff works.
> 
> The only people really noticing problems with this are 
> hobbyists and most likely the gaming crowd trying to setup 
> their own gameserver and finding out that they are stuck 
> behind this thing called "NAT".
> 
> P2P people, thus quite a large group of people using the 
> Internet today, have their tools to nice NAT tricks, thus 
> these won't notice it.
> 
> And for the rest of the population the Internet consists of 
> http:// and https:// if they even recognize those two things, 
> thus most likely only "www" and "email", the latter likely 
> only over a webinterface...
>

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 21 Sep 2007 09:14:02 -0700

At 12:34 PM +0200 9/21/07, Patrick Vande Walle wrote:
>proposal to the board, and this is exactly what I intend to do.

Great!

>Keep in

Maybe the proposal should come from someone less pessimistic than 
you, then. A good proposer would be someone who believes that they 
can bridge the disparate communities and is willing to participate in 
the bridging work, not just the work on one side of the bridge or the 
other. There are plenty of people at ISOC who have spent more than a 
decade working on both sides of the bridge.

>not supported, I won't spend more time on it.

Spending the time of an organization that is meant to be bridging the 
communities seems more worthwhile for everyone than asking one group 
to greatly expand its scope into areas where it has no particular 
skills.

--Paul Hoffman, Director
--VPN Consortium

---

From: Dave Crocker <[email-masked]>
Date: Fri, 21 Sep 2007 10:20:52 -0700

Eliot Lear wrote:
>      there was something of a view that the whole point of 

+1

UUCP, Bitnet, CSNet, oh and let's not forget Arpanet-to-Internet transition 
(FTP to SMTP mail)...

Administrative boundaries are not just bookkeeping constructs. They can have 
fundamentla technical impact.  Take, for example, exterior routing technology 
versus interior.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Keith Moore <[email-masked]>
Date: Fri, 21 Sep 2007 16:37:15 -0400

You seem to be of the impression that whether something "works" is
binary.  If a hack "works" in some situations and breaks things in
others, does it work or is it broken?  Note that different people will
come up with different opinions on whether the hack works or not,
depending on what apps they run, their role (are they users, or
application vendors whose market decreases and support costs increase
when network operators put in these hacks?), and so forth.

It has nothing to do with being a purist.  A hack that causes a 1%
failure rate is a lot more costly to some users than to others.  That
failure rate is low enough that ISPs can get into denial about whether
the failure exists and refuse to fix it.  But the users and application
vendors suffer nonetheless.

Here's the rule that should be followed: If your service or product
doesn't adhere to the standards, you're responsible for whatever
breakage results.

Keith

7.0.0.1])
	by shu.cs.utk.edu (Postfix) with ESMTP id C7B081EE2FD;
	Fri, 21 Sep 2007 16:37:35 -0400 (EDT)
Date: Fri, 21 Sep 2007 16:37:15 -0400
From: Keith Moore <[email-masked]>
To: [email-masked]
OpenPGP: id=E1473978
Cc: [email-masked]
Subject: Re: ideas getting shot down

You seem to be of the impression that whether something "works" is
binary.  If a hack "works" in some situations and breaks things in
others, does it work or is it broken?  Note that different people will
come up with different opinions on whether the hack works or not,
depending on what apps they run, their role (are they users, or
application vendors whose market decreases and support costs increase
when network operators put in these hacks?), and so forth.

It has nothing to do with being a purist.  A hack that causes a 1%
failure rate is a lot more costly to some users than to others.  That
failure rate is low enough that ISPs can get into denial about whether
the failure exists and refuse to fix it.  But the users and application
vendors suffer nonetheless.

Here's the rule that should be followed: If your service or product
doesn't adhere to the standards, you're responsible for whatever
breakage results.

Keith

---

From: Greg Skinner <[email-masked]>
Date: Sun, 23 Sep 2007 03:09:41 +0000

> don't know what is possible and what they are missing.

Arguably, anyone can join the IETF, and represent themself.  However,
there is a steep learning curve, especially for those people who don't
have much if any technical background, in order to participate
meaningfully.

For example, I know of people who would like IP addresses to encode
physical locations such as the country and city, so they can use this
information to decide which ads to serve (or to block), or to enforce
DRM.  But if they come to the IETF lists and ask for this capability
(or why it can't be provided), at best, they'll be told that's not the
way things are done.  Instead, they go to companies that are willing to
sell them databases that presumably map IP addresses geographically to
a high degree of accuracy, at least to the country level.

> "www" and "email", the latter likely only over a webinterface...

Actually, one could argue that this suggests that NAT is an
engineering success, even if it is architecturally flawed, because it
serves the needs of a majority of users, causes problems in only a few
cases, and isn't mandatory.  Users can get non-NAT access, depending
upon how much money and/or effort they're willing to expend. (Granted,
this doesn't take into account the arguments about how future
applications may be inhibited by NAT, or how certain security measures
are more difficult to enforce.)

> Last time I checked the IETF was doing protocols and not user interfaces.

I'd like to see the general level of user understanding of the
capabilities of Internet protocols raised.  However, I don't know how
this can be accomplished without a lot of effort on the users' parts
to come up to speed.

--gregbo