Subject: I-D ACTION:draft-ietf-ipv6-ula-central-02.txt

From: [email-masked]
Date: Mon, 18 Jun 2007 15:50:02 -0400

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the IP Version 6 Working Group Working Group of the IETF.

	Title		: Centrally Assigned Unique Local IPv6 Unicast Addresses
	Author(s)	: R. Hinden, B. Haberman
	Filename	: draft-ietf-ipv6-ula-central-02.txt
	Pages		: 11
	Date		: 2007-6-18
	
This document defines Centrally allocated IPv6 Unique Local
   addresses.  These addresses are globally unique and are intended for
   local communications, usually inside of a site.  They are not
   expected to be routable on the global Internet.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipv6-ula-central-02.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-ipv6-ula-central-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ipv6-ula-central-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Paul Vixie <[email-masked]>
Date: Thu, 28 Jun 2007 04:05:09 +0000

these are my comments on the following I-D:

> <http://www.ietf.org/internet-drafts/draft-ietf-ipv6-ula-central-02.txt>

first, in 3.1, this table:

      | 7 bits |1|  40 bits   |  16 bits  |          64 bits           |
      +--------+-+------------+-----------+----------------------------+
      | Prefix |L| Global ID  | Subnet ID |        Interface ID        |
      +--------+-+------------+-----------+----------------------------+

should be replaced with this one:

      | 7 bits |1|  8 bits  | 16 bits | 16 bits | 80 bits  |
      +--------+-+----------+---------+---------+----------+
      | Prefix |L| Reserved | RIR Num | LIR Num | User Num |
      +--------+-+----------+---------+---------+----------+

where "Prefix" and "L" are defined as shown in central-02, and the other
fields are defined as follows:

     Reserved            Set to 0 by all implementors of this specification,
                         but may be set to nonzero by implementors of a later
                         specification.

     RIR Num             Identifiers assigned by IANA for each /16 as
                         allocated to an Regional Internet Address Registry
                         (RIR).  For direct allocations by IANA, the value
                         of zero (0x0000) is reserved.

     LIR Num             Identifiers assigned by RIR for each /32 as
                         allocated to a Local Internet Address Registry (LIR).
                         For direct allocations by an RIR, the value of zero
                         (0x0000) is reserved.

     User Num            Identifier assigned by an end user or network
                         operator who implements this specification.

second, delete all of section 3.2 including subsections 3.2.1, 3.2.2, 3.2.3.

third, replace section 7.0 with the following:

---

7.0 IANA Considerations

    IANA is hereby instructed to reserve address block FC::/7 for private
    unique addresses, and to allocate /32 blocks to Regional Internet 
    Address Registries (RIRs) who request same after adopting policies
    consistent with this specification.  Allocation shall be similar in
    all ways to normal IANA address allocation to RIRs, including but not
    limited to IN-ADDR.ARPA delegations and WHOIS records.

---

Paul Vixie
not speaking for ISC
not speaking for ARIN

---

From: Scott Leibrand <[email-masked]>
Date: Wed, 27 Jun 2007 22:28:55 -0700

I would support Paul's proposed changes below, and the resulting draft.

-Scott

---

From: Roger Jorgensen <[email-masked]>
Date: Thu, 28 Jun 2007 08:20:11 +0200 (CEST)

On Thu, 28 Jun 2007, Paul Vixie wrote:
<snip>
>      | 7 bits |1|  8 bits  | 16 bits | 16 bits | 80 bits  |

striks me as almost the same as the good old sTLA...

<snip>
>    limited to IN-ADDR.ARPA delegations and WHOIS records.

so we are talking about full reverse control delegated to the person that 
get this ULA-C block?

except this piece about DNS mention above it look more promissing than the 
original draft.

-- 

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

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 28 Jun 2007 10:28:31 +0200

> I would support Paul's proposed changes below, and the resulting draft.

I wouldn't, at this time. We need to see where the RAM/RRG discussions
lead. If they lead to a clear need for registered globally unique
identifiers in IPv6 address format, something like this might be right
(unless we also need a cryptographic property).

I have a strong feeling there is no consensus forming...

     Brian

---

From: Jeroen Massar <[email-masked]>
Date: Thu, 28 Jun 2007 11:24:41 +0100

Paul Vixie wrote:
[..]
> first, in 3.1, this table:
[..]
>       | 7 bits |1|  8 bits  | 16 bits | 16 bits | 80 bits  |

Looks okayish but does bring back the idea of sTLA's a bit. But there is
another thing that this causes: it sort of allows aggregation.

How is this any different at all from what I proposed in another
message: One setups an organization called "Local IP Addresses Org" and
sets up an LIR, requests a /32, one one has 65k /48's to provide to
endusers. Members have a share in the org, and each and every single one
of them can already make sure that the LIR fees are paid (there are no
equipment or transit etc fees) and presto. You have EXACTLY what you
have above, but with the added benefit that it is globally unique
address space with full RIR support. The LIR can shoot ip6.arpa
delegations per /48 if they want directly into the RIR's nameservers,
thus that is also covered. Connectivity one could also provide just like
a normal LIR if really wanted.

Another problem with the above is that it doesn't allow for direct
end-user assignments. Folks still have to go through a LIR. This thus
doesn't provide these people with a "direct assignment" and they are
still bound to the LIR.

From what I understand the people who really want this kind of "local"
address space want to have a *direct* assignment from a RIR or IANA.
This as it is expected that a RIR won't go belly up, a LIR might do so
though.

As such, if you really want to have ULA-C (which I really think is
unnecessary because of arguments I've reiterated a couple of times
already also in other messages and the above) I would at least propose:

| 7 bits |1| 8 bits |16 bits| 16 bits |  16 bits  | 64 bits   |
+--------+-+--------+-------+---------+-----------+-----------+
| Prefix |L|Reserved|RIR ID | Site ID | Subnet ID | Iface ID  |
+--------+-+--------+-------+---------+-----------+-----------+
                                      | /48 for the end-site  |
                                      +-----------------------+

Same scheme of allocation, but takes out the LIR portion and thus allows
RIR's to delegate this directly to endusers.

[..]
> second, delete all of section 3.2 including subsections 3.2.1, 3.2.2, 3.2.3.

Agree.

> third, replace section 7.0 with the following:

Don't agree at all. (btw it is fc00::/7 not fc::/7 :)

The moment you introduce support for IP6.ARPA (not IN-ADDR.ARPA) and
require delegations to be possible there really is no difference between
PI and this kind of address space (except the prefix from which they are
allocated, they can be filtered on that but still).

The reasons against having support for reverse DNS:
 - You are introducing a *local* space into the *global* Internet.
   As such it is required to have Internet connectivity (with all the
   hacks that are required to be able to talk to the ip6.arpa servers
   and the chain along it to get to those reverse DNS servers).

   One thus has to setup "DNS gateway" boxes for reverse DNS which
   are able to contact the global Internet to reach those machines.
   If you can set those up, why not configure them directly with the
   content of your *local* zones.

   Also, it only covers the *reverse* of this address space, it does not
   solve the *forwards* that point to the address space. It might be
   just me, but users type forward more than reverses.
   One will thus have to merge forward zones anyway, if you can do that
   you can also setup a reverse zone at the same time.

 - Introducing the ability to have ip6.arpa delegations will make sure
   that the RIR will have to do more work for this. The delegations
   have to point to DNS servers on the *public* Internet (strange as
   we are talking about *local* addresses :) These DNS servers thus
   have to be either on stable IP's (as such every such organization
   requires to have also a Public PI space for this solely (they can't
   depend on the local space to be PA so why should they for the global
   block?) The other would be that they keep asking the RIR all the time
   to change the DNS server delegation as they swapped ISP's again.
   This thus costs the RIR a lot of resources/time/bla and thus is more
   costly than having the requester simply have PI space.

If one *really* requires that there will be reverse that is
'automatically setup' (ignoring that you still have to do it for the
forward) then define in the draft the method that James Woodyatt
proposed of using synthesized reverse records for 0.0.c.f.ip6.arpa.
And then simply declaring that the highest subnet (::ffff:<64bits>)
contains at ::53 a DNS server serving reverse ip6.arpa for that zone.

Easiest of course is to simply set up the forward+reverse servers at the
point where you interconnect with the other network. If one says "but we
interconnect automatically", then also add in that automated framework a
way of exchanging DNS servers and zones.

The big question with all of this really is: why can't these people who
need this address space (still I haven't seen a good use-case*) simply
use PI? As that is what they really need, nothing else. If they need
something else, then please define why they need something else and what
that something else is. Having a solution for an unknown problem is not
the way to go IMHO.

Now, I hope that the above was constructive ;)

Greets,
 Jeroen

* = I did see the one about planes flying around the world who have
their internal systems in a static /48 and when they come to other
places they can automatically interconnect to those networks, but why
can't those use PI either? :)

---

From: Paul Vixie <[email-masked]>
Date: Thu, 28 Jun 2007 14:44:31 +0000

> striks me as almost the same as the good old sTLA...

as with many other old things that become new, we know a lot more now about
what we're trying to do than we did before, and the "almost" is important,
this isn't sTLA.

> so we are talking about full reverse control delegated to the person that

yes.

> except this piece about DNS mention above it look more promissing than the

fred templin has made a compelling case here that the ad-hoc nature of ULA-C
routing precludes the normal "put override configs in every resolver" logic
described in RFC 1918.  for PTR lookups to work in fred's case, there has to
be global DNS.  note that global DNS isn't a requirement -- anyone with ULA-C
who prefers to use RFC 1918-like overrides in all their own resolvers can do
that.  the instructions in the replacement for section 7.0 above are there to
ensure that those who want their ULA-C PTRs to be in the global DNS can have
that.  (if you don't like it, then don't use it, but don't tell others they
can't have it either, please.  if they want it, let them have it, please.)

---

From: Paul Vixie <[email-masked]>
Date: Thu, 28 Jun 2007 14:47:37 +0000

Brian E Carpenter <[email-masked]>:
> 
> Scott Leibrand <[email-masked]>:
> > 

where are those discussions being held, and can you post a summary, and why
are we wasting our keystrokes discussing this if there's a preclusive topic
being discussed somewhere entirely else?

> I have a strong feeling there is no consensus forming...

i disagree, i've been immersed in this for a month now, and my draft edits
as proposed last night represent my understanding of a potential consensus,
which unlike you i can feel forming.

---

From: Paul Vixie <[email-masked]>
Date: Thu, 28 Jun 2007 15:00:52 +0000

Jeroen Massar <[email-masked]>:
> 
> Paul Vixie <[email-masked]>:
> > 

i'd say deliberately not.  if LIR's receive /48's then when they hand out
address space to end sites it'll be in groups of 5 and 10 /64's.  we can
add text recommending that RIR's and LIR's deliberately randomize or skip
even/odd or something to prevent accidental or opportunistic aggregation,
though.

> endusers.

you are so prolific here that your own words got lost in your own torrent?

> Members have a share in the org, and each and every single one
> address space with full RIR support.

except that payments and shares are out of scope, you might be right.

> doesn't provide these people with a "direct assignment" and they are

then you didn't read my text, because it says the opposite of that assertion.

> | 7 bits |1| 8 bits |16 bits| 16 bits |  16 bits  | 64 bits   |

i don't use /64's for my links.  EUI64 is going to die, and die hard.  let's
not overspecify the mantissa.  i said "80 bits for User Num" and i meant that.
(if someone wants to use /64's for their links, they can do that under this
proposal, but we can't reasonably require it, and the recommendations for it
are already present in plenty of other RFCs.)

> RIR's to delegate this directly to endusers.

read my text.  direct allocations are already possible.

> Don't agree at all. (btw it is fc00::/7 not fc::/7 :)

i've seen plenty of people say fc00::/7 and i just don't get it.  you might
as well say fc00:0000:0000:0000:0000:0000:0000:0000/7.  when i wrote the
reference implementation of inet_ntop(), i only emitted the part of the
mantissa that was actually covered by the cidrlen.  this isn't scientific
notation where you want to show the degree of accuracy of your measurements.

> allocated, they can be filtered on that but still).

fred made a compelling case for why ad-hoc ULA-C routing precluded the kind
of resolver config overrides that we're supposed to use for RFC 1918.  any
ULA-C user who doesn't want their PTR's in the global DNS should not put any
there, but it's not our place here and now to tell them that they just can't.

> If one *really* requires that there will be reverse that is 'automatically
> setup' (ignoring that you still have to do it for the forward) then define
> in the draft the method that James Woodyatt proposed of using synthesized
> reverse records for 0.0.c.f.ip6.arpa.  And then simply declaring that the
> highest subnet (::ffff:<64bits>) contains at ::53 a DNS server serving
> reverse ip6.arpa for that zone.

this is attractive, but it's an architectural change that we'd have to review
for other connectivity realms, like the DFZ, and i don't want to argue it as
part of settling the ULA-C question.  if you like this idea, propose it and
let's get into its merits and implications.

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 28 Jun 2007 08:14:15 -0700

My use case questions that still need to be satisfied are:

  1) can any site (large or small) get a ULA-C?
  2) can the ULA-C's be obtained at a nominal cost?
  3) can the ULA-C's be published in the global DNS
     forward and reverse?
  4) can the ULA-C's be kept out of the DFZ?

If Paul's proposal answers all of these as "yes", then
I have no objections.

Fred
[email-masked]

> -----Original Message-----
> From: Paul Vixie [mailto:[email-masked]] 
> Sent: Wednesday, June 27, 2007 9:05 PM
> To: [email-masked]
> Subject: Re: I-D ACTION:draft-ietf-ipv6-ula-central-02.txt 
>

---

From: Roger Jorgensen <[email-masked]>
Date: Thu, 28 Jun 2007 17:34:05 +0200 (CEST)

<snip>
> which unlike you i can feel forming.

Paul's suggestion did sound okay and guess there can be a potential 
consensus on that one?

--

---

From: Paul Vixie <[email-masked]>
Date: Thu, 28 Jun 2007 16:08:37 +0000

> From: "Templin, Fred L" <[email-masked]>
> 

yes to all four.

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 28 Jun 2007 09:18:14 -0700

Maybe I should have qualified 2) by asking how nominal is
"nominal"? Just as reminder, I have already stated that my
opinions do not necessarily reflect a corporate position:

http://www1.ietf.org/mail-archive/web/ipv6/current/msg07620.html

Fred

> Sent: Thursday, June 28, 2007 9:09 AM
> To: Templin, Fred L
> Cc: [email-masked]

---

From: Paul Vixie <[email-masked]>
Date: Thu, 28 Jun 2007 16:36:05 +0000

> Maybe I should have qualified 2) by asking how nominal is "nominal"?

ietf does not control the costs of this kind of operational activity.  all
that an rfc can do is ask that the costs be nominal and direct iana to only
give address space out to rir's who have adopted policies consistent with
the specification.  presumably iana will look to the rir's, which have strong
and open bottom-up governance models, to determine the meaning of "nominal".

---

From: Christian Huitema <[email-masked]>
Date: Thu, 28 Jun 2007 09:39:35 -0700

I would support Paul proposal, but with one small change. Paul proposes

> >       | 7 bits |1|  8 bits  | 16 bits | 16 bits | 80 bits  |

That is fine, but I would rather call the delegation field by a
different name than "RIR Num". Call in it RIR assumes that the numbers
can only be allocated by the current set of regional registries. I don't
see any technical reason to carve this policy in a standard. I would
much prefer a neutral designation, e.g. "Registry Number".

-- Christian Huitema

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 28 Jun 2007 09:42:39 -0700

> From: Christian Huitema [mailto:[email-masked]] 
> Sent: Thursday, June 28, 2007 9:40 AM
> To: Templin, Fred L; Paul Vixie; [email-masked]
> Subject: RE: I-D ACTION:draft-ietf-ipv6-ula-central-02.txt 
> 

I agree.

Fred

---

From: james woodyatt <[email-masked]>
Date: Thu, 28 Jun 2007 10:35:13 -0700

On Jun 28, 2007, at 03:24, Jeroen Massar wrote:
> 'automatically setup' (ignoring that you still have to do it for  
> the forward) then define in the draft the method that James  
> Woodyatt proposed of using synthesized reverse records for  
> 0.0.c.f.ip6.arpa.  And then simply declaring that the highest  
> subnet (::ffff:<64bits>)

I don't think I can claim full credit for this idea.  I think  
Christian Huitema posted first.  The proposal is just for  
automatically delegating the authoritative name service for reverse  
DNS to ULA-C address space.

(p.s. I also like the idea of defining an anycast identifier for DNS  
resolving proxy servers in the locally preferred horizon.  I  
understand, however, that *that* idea is more controversial-- though  
I don't understand why it should be.  At the risk of derailing the  
topic, I'd like to mention that I know of at least one consumer  
Internet gateway product that advertises its DNS proxy service with  
IPv6 multicast DNS with a SRV records for _domain._udp.local and  
_domain._tcp.local pointing to the AAAA records for the gateway.   
This was done because there was no anycast identifier for nodes on  
unmanaged networks to find their preferred DNS proxy.)

--
james woodyatt <[email-masked]>
member of technical staff, communications engineering

---

From: james woodyatt <[email-masked]>
Date: Thu, 28 Jun 2007 10:56:51 -0700

> much prefer a neutral designation, e.g. "Registry Number".

Actually, I think for DNS operation purposes, it makes more sense to  
reserve the RIR Num field for the existing regional registries.   
Registries that aren't RIRs can be assigned by IANA directly from the  
RIR=0 space.

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 28 Jun 2007 11:07:19 -0700

> From: james woodyatt [mailto:[email-masked]] 
> Sent: Thursday, June 28, 2007 10:57 AM
> To: IETF IPv6 Mailing List

I still agree with Christian that there is no technical
reason to build policy into the standard. Also, IMHO,
this is discussion is coming close to diverging from
the technical realm and entering into "Big Business".

Fred

---

From: Jeroen Massar <[email-masked]>
Date: Thu, 28 Jun 2007 19:39:59 +0100

[Two for the price of one response, response to James far below]

Paul Vixie wrote:
> address space to end sites it'll be in groups of 5 and 10 /64's.

This is not according to current RIR policies or according to current
IETF numbering plans. It also completely ignores the EUI-64 paradigm.
When the bits are assigned to an operator they can already choose to do
whatever they want with it.

A site currently gets a /48. If that has to change then support
draft-narten-iana-rir-ipv6-considerations to change that (I do btw as
endsite will never ever ever use a /48 under normal circumstances, and a
/56 will be enough for an expected 99% of them).

> you are so prolific here that your own words got lost in your own torrent?

I can draw it out if you want (you know how this works, but here goes):

+------+       +-----+       +-----+       +---------+
| IANA | ----> | RIR | ----> | LIR | ----> | Endsite |
+------+       +-----+       +-----+       +---------+

This is how current address assignments are done:
* IANA has it all
* RIR gets a chunk allocated from IANA
* LIR gets a chunk allocated from RIR
* Endsites get an assignment (not an allocation) from their LIR.

To note, you have "LIR" in your address diagram, and thus similar with
current policies, the endsite gets a block from the LIR, not from the
RIR, as such there is _no_ direct assignment from RIR to Endsite, and
that is (from what I understand) what people 'needing' ULA-C kind of
addresses want as they have a fear of the LIR going belly up and them
loosing their assignment.

What I proposed, lets rewrite it again: Several Endsites together set up
a single LIR, they request a /32, take /48's out of this and use this
for 'private space'. Presto. In current address space and not requiring
any changes updates or new weird rules. Also covers forward/reverse etc.

I have to note that "LIR" is a bit different term in RIPE and ARIN land,
thus it might be that that is the confusing part, in APNIC and some
other regions there are also NIR's in the chain. Making the last part
(LIR + User Num) into "User Num" would resolve this.

> except that payments and shares are out of scope, you might be right.

Isn't the MAIN reason that people want ULA-C that they want it "CHEAP"!?
How is it then suddenly out of scope?

Also, clearly by defining ULA-C this shows that there is a price on
address space, I hope that at least the IETF is not going there.

> then you didn't read my text, because it says the opposite of that assertion.

See my IANA->RIR->LIR->Endsite Diagram, and then check the "RIR" and
"LIR" portion in your address-diagram. Because you include LIR there can
not be a direct endsite allocation. If you would change that, as I did
in my proposed diagram to a "Prefix|L|Res|RIR|SiteID|UserBits" then you
can have a direct assignment from RIR->Endsite. (Changed "Subnet|Iface"
to "UserBits" to show that those bits really are determined by the
network operator and nobody else.

[..]
> i don't use /64's for my links.

And nobody forces you or anybody else to do so. All the other IETF
documents do include them though and if this defines address space it
should include them also IMHO. Though, I can certainly live when it is
just defined as "user defined space".

> EUI64 is going to die, and die hard.

I did not see a draft about it yet. But I do understand your arguments
for it. Still, as mentioned, the address space belongs to the operator,
let them enjoy using it. The trick of course is that devices actually do
support routing on the full 128 bits, but that is afaik still the case
with current hardware and also implicit in the IPv6 RFCs.

> let's not overspecify the mantissa.  i said "80 bits for User Num" and i meant that.

I can agree with the above.

> read my text.  direct allocations are already possible.

No they are not, as a LIR is not an endsite. As such an endsite always
has to go to a LIR. That is also the whole point of PI.

Taking the LIR part out of the address diagram would resolve that part
of my comment.

> as well say fc00:0000:0000:0000:0000:0000:0000:0000/7.

Well it is simple hex math: 0xfc00 != 0x00fc

Unless you are mixing up Big Endian and Little Endian comparisons.
The /7 would always mask out the last 121 bits as such fc::/7 == ::/7
and thus is wrong.

According to you is "fc::1" == "fc00:0000:0000:0000:0000:0000:0000:0001"
or is it "00fc:0000:0000:0000:0000:0000:0000:0001" ?

See the ambiguity? Also when you have the first (fc00::1) and take the
/7 it will become fc00::/7, while the latter would be come ::/7.

> when i wrote the

Well maybe the reference implementation is wrong? :)
But either you are wrong, or I am wrong (which is not unlikely ;), and
in either case I guess we end up fixing up a lot of software that is
already deployed and actively using it.

The actual function that will break with the above is inet_pton() which
converts from human readable to computer bits.

As you made me doubt about it, I just had to test it out. I couldn't
find a single box though (tried Linux,FreeBSD,WinXP,OpenBSD,NetBSD,AIX)
which did it the way you describe. See the test program way below so
that you can also test it out.

> there, but it's not our place here and now to tell them that they just can't.

That is the wrong answer for this question. The question is not why they
can't, the question is why they want it. And moreover: why is PI not
good enough for this purpose?

> let's get into its merits and implications.

As mentioned, I don't like the idea as it solves a problem which should
be solved by other means. It also still requires that one configures
forward resolvers anyway. See below for James mail which has a much
better way to resolve this whole "reverse" problem of the ULA portion.

Anyway my ignored question again:

 Why would the global DNS have to handle *LOCAL* DNS delegations.

(Which never should occur/be used globally. Which most likely can not be
queried globally and which also has no value at all globally. Not even
thinking about security-minded folks who do not want to expose their
internal DNS names to the global world, that is why they want it
locally. Indeed one can opt to NOT use it, but then we just have lame
delegations again causing queries there to hit the DNS servers (most
likely the RIR ones).

If ULA-C is going to exist it should, just like ULA (RFC4193) should be,
included in the AS112 set of zones.

james woodyatt wrote:
> resolving proxy servers in the locally preferred horizon.I understand,
> however, that *that* idea is more controversial-- though I don't
> understand why it should be.

dnsop group in Paris told me that it was something with breaking 3 holy
wars that have been discussed to death over the years.

From my POV there is no difference between a well known anycast DNS
server or an ISP telling clients that their DNS server is x.y.z.w.
Anycast is just a nice tool to make them failover easily and to provide
best service possible.

>  At the risk of derailing the topic, I'd
> like to mention that I know of at least one consumer Internet gateway
> product that advertises its DNS proxy service with IPv6 multicast DNS
> with a SRV records for _domain._udp.local and _domain._tcp.local
> pointing to the AAAA records for the gateway.  This was done because
> there was no anycast identifier for nodes on unmanaged networks to
> find their preferred DNS proxy.)

The problem with that still is that you only have 1 DNS server and that
doesn't say if it is the forward or the reverse. If one defines
<prefix>::53 to be DNS, it can only handle reverse zones, not forward as
when I ask for "example.com" to my local DNS server how is it to know
that it should ask <otherprefix>::1 for this?

Although as the above is mDNS, it might be that you can get back a
response from another server which does know how that zone works?

Nevertheless, for the "Auto-joining MANET case", the protocol that
setups the routing can also set up the DNS merger. This has to happen
anyway when the root DNS servers are in far-far-away-never-reach-land.

Greets,
 Jeroen

--
$ cc -o bla bla.c
8<==================================================================
#include <stdio.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <arpa/inet.h>

void convert(const char *prefix, unsigned int length)
{
        struct in6_addr a6;
        char            buf[1024];
        unsigned int    i = (128/8)-1, l = 128 - length;

	if (length>128)
	{
		printf("Prefixlength for %s too large %u>128\n",
			prefix, length);
		return;
	}

        printf("%s/%u\n", prefix, length);

        /* Show us the number */
        inet_pton(AF_INET6, prefix, &a6);

        /* Show us the number without applying the prefixlength */
        inet_ntop(AF_INET6, &a6, buf, sizeof(buf));

        printf("\tntop: %s\n", buf);

        /* Zero out the last bits, thus applying the prefixlength */
        while (l > 8)
        {
                a6.s6_addr[i] = 0;
                i--;
                l-=8;
        }

        if (l > 0)
        {
                a6.s6_addr[i] &= ((0xff << l) & 0xff);
        }

        inet_ntop(AF_INET6, &a6, buf, sizeof(buf));
        printf("\tzero: %s/%u\n", buf, length);
}

int main(void)
{
        convert("fc::1",        128);
        convert("fc::2",          0);
        convert("fc::3",          7);
        convert("fc::4",          8);

        convert("fc00::11",     128);
        convert("fc00::12",       0);
        convert("fc00::13",       7);
        convert("fc00::14",       8);

        convert("00fc::21",     128);
        convert("00fc::22",       0);
        convert("00fc::23",       7);
        convert("00fc::24",       8);

        convert("ffff::31",     128);
        convert("ffff::32",       0);
        convert("ffff::33",       7);
        convert("ffff::34",       8);
        convert("ffff::35",       4);
}
==================================================================>8

fc::1/128
        ntop: fc::1
        zero: fc::1/128
fc::2/0
        ntop: fc::2
        zero: ::/0
fc::3/7
        ntop: fc::3
        zero: ::/7
fc::4/8
        ntop: fc::4
        zero: ::/8
fc00::11/128
        ntop: fc00::11
        zero: fc00::11/128
fc00::12/0
        ntop: fc00::12
        zero: ::/0
fc00::13/7
        ntop: fc00::13
        zero: fc00::/7
fc00::14/8
        ntop: fc00::14
        zero: fc00::/8
00fc::21/128
        ntop: fc::21
        zero: fc::21/128
00fc::22/0
        ntop: fc::22
        zero: ::/0
00fc::23/7
        ntop: fc::23
        zero: ::/7
00fc::24/8
        ntop: fc::24
        zero: ::/8
ffff::31/128
        ntop: ffff::31
        zero: ffff::31/128
ffff::32/0
        ntop: ffff::32
        zero: ::/0
ffff::33/7
        ntop: ffff::33
        zero: fe00::/7
ffff::34/8
        ntop: ffff::34
        zero: ff00::/8
ffff::34/4
        ntop: ffff::34
        zero: f000::/4

---

From: Paul Vixie <[email-masked]>
Date: Thu, 28 Jun 2007 20:05:16 +0000

On Jun 28, 2007, at 09:39, Christian Huitema wrote:
> 
> I would support Paul proposal, but with one small change.  Paul proposes a
> delegation hierarchy in the ULA-C space:
>
> > That is fine, but I would rather call the delegation field by a different
> > name than "RIR Num".  Call in it RIR assumes that the numbers can only be
> > allocated by the current set of regional registries.

where in my diffs do i restrict RIRs to the current set of RIRs?  it's expected
that there may be more RIRs in the future.  it's also very likely that /32's
will be handed out in blocks of five or ten to RIRs who request this kind of
space from IANA, similar to the way AS numbers are done.

> > I don't see any technical reason to carve this policy in a standard. I
> > would much prefer a neutral designation, e.g. "Registry Number".

i deliberately did not use the word "ID" since i expect each RIR to request
more than one of these /32's.  i'd avoid "Registry Number" for similar reasons.

james woodyatt <[email-masked]> wrote:
> 
> Actually, I think for DNS operation purposes, it makes more sense to reserve
> the RIR Num field for the existing regional registries.  Registries that
> aren't RIRs can be assigned by IANA directly from the RIR=0 space.

the text i submitted, which more than one person here has now demonstrated
that they did not read, explicitly reserves RIR Num 0 for direct IANA
allocations.  (not that there's any IANA policy allowing such allocations,
but if there ever is one, this is the bit pattern that would represent it.)

---

From: Paul Vixie <[email-masked]>
Date: Thu, 28 Jun 2007 20:07:37 +0000

[email-masked] wrote:

> I still agree with Christian that there is no technical reason to build
> policy into the standard. Also, IMHO, this is discussion is coming close to
> diverging from the technical realm and entering into "Big Business".

while it's probably more correct, in terms of organizational layering, for IETF
to specify only the top 8 bits of these addresses and say "let the ASO decide
how to carve it up for the RIRs", i think we can do better, and safely too.  we
ought to be able to paint enough of a picture that even end users can see their
place in the solution just from this RFC alone.

---

From: Scott Leibrand <[email-masked]>
Date: Thu, 28 Jun 2007 13:16:43 -0700

> and open bottom-up governance models, to determine the meaning of "nominal".

To offer a prediction, I would suspect that, at least for ARIN, 
registrants receiving only a single block of this type of address space 
would fall into the bin that gets charged $100/year today.  To me, that 
is a reasonable price to pay for maintaining WHOIS and DNS registration 
information.  Of course, RIRs could always choose to use a different 
cost structure for such assignments.

-Scott

---

From: Roger Jorgensen <[email-masked]>
Date: Thu, 28 Jun 2007 22:40:57 +0200 (CEST)

On Thu, 28 Jun 2007, Scott Leibrand wrote:
> To offer a prediction, I would suspect that, at least for ARIN, registrants 
> receiving only a single block of this type of address space would fall into 
> the bin that gets charged $100/year today.  To me, that is a reasonable price 
> to pay for maintaining WHOIS and DNS registration information.  Of course, 
> RIRs could always choose to use a different cost structure for such 
> assignments.

Think it is completly out of this scope to define anything at all related 
to the cost of this, but I would rather consider this a bit like the 
domain charging system when thinking in term of what it should cost...

--

---

From: Roger Jorgensen <[email-masked]>
Date: Thu, 28 Jun 2007 22:45:23 +0200 (CEST)

> being discussed somewhere entirely else?

[email-masked] and I gave up following that discussion months ago. Way too 
much chitchat one way or the other as I see it and no real consensus 
forming in one way or another.

Don't think we should wait for RAM/RRG to agree, let us agree on our 
understanding and at a later stage when they have come up with a "final" 
solution we can compare our understanding with their and see if there 
is a need for adjustment.

--

---

From: "Kevin Kargel" <[email-masked]>
Date: Thu, 28 Jun 2007 16:01:16 -0500

I am afraid I am slow..  I still don't get the need to publicly
advertise DNS for ULA(-x) .. if your neighbor cannot route to your ULA
he doesn't need to know what it's names are..  if you do allow him to
enter your network via VPN or whatever there is either a dhcp-like
process by which he is granted an address which will also give him a
name server to use, or when he says "Hey, Can I have access to your
network" you can say "Sure, here are your credentials and my DNS server
is..." 

Then of course because you can populate your DNS server with whatever
zones you want when your neighbor queries your name server it will tell
him what he wants to know.

Aren't your DNS servers going to provide different views for clients
coming from PI or PA than they do for clients coming from ULAx anyway?
or is your network going to be a completely glass house?   Typically
"local" clients get more access and information than non-local clients.

> Sent: Thursday, June 28, 2007 12:35 PM
> automatically delegating the authoritative name service for 
> reverse DNS to ULA-C address space.
> 
> (p.s. I also like the idea of defining an anycast identifier 
> for DNS resolving proxy servers in the locally preferred 
> horizon.  I understand, however, that *that* idea is more 
> controversial-- though I don't understand why it should be.  
> At the risk of derailing the topic, I'd like to mention that 
> I know of at least one consumer Internet gateway product that 
> advertises its DNS proxy service with
> This was done because there was no anycast identifier for 
> nodes on unmanaged networks to find their preferred DNS proxy.)
> 
> 
> --

---

From: Roger Jorgensen <[email-masked]>
Date: Thu, 28 Jun 2007 23:13:07 +0200 (CEST)

> doesn't provide these people with a "direct assignment" and they are

too complicated and see bellow why.

<snip>
> | 7 bits |1| 8 bits |16 bits| 16 bits |  16 bits  | 64 bits   |

no, just forget all of that. The original text from Paul have the solution 
to this very clear:

<paste>
      RIR Num             Identifiers assigned by IANA for each /16 as
                          allocated to an Regional Internet Address
 			Registry
                          (RIR).  For direct allocations by IANA, the value
                          of zero (0x0000) is reserved.

      LIR Num             Identifiers assigned by RIR for each /32 as
                          allocated to a Local Internet Address Registry (LIR).
                          For direct allocations by an RIR, the value of
 			zero  (0x0000) is reserved.
</end paste>

so we don't have to consider this at all!! All we have todo is let IANA, 
or other parties getting this task from IANA, run something automatic on 
THEIR side that give end-user direct request possibility without going 
through a RIR or LIR.

This solution suite the need at my workplace perfect.

<snip>
>   and the chain along it to get to those reverse DNS servers).

as someone said to me earlier... in times of complicated affairs and 
compromisses you might have to swallow a few hard pills... I dislike the 
thought of ULA-C but this latest suggestion is reasonable and not that 
bad. Even with DNS in place it is acceptable for me personaly this way of 
doing it.

It has been said very clear by many that ULA-C is _not_ considered to be 
global reachable and if we just can as strong as possible make it clear 
DURING requesting of addresses we should be fine. The point is that we 
have to show the enduser that they have agreed that they can NOT demand 
global routing of this address space at all. No complicated text, keep it 
simple.

--

---

From: Roger Jorgensen <[email-masked]>
Date: Thu, 28 Jun 2007 23:30:31 +0200 (CEST)

Hi all,

if we overlook the last part about DNS for now, is this acceptable by 
people? I've read this through several times and I belive it satifsy the 
following asked by "Templin, Fred L" <[email-masked]>

i've removed part 3 on purpose since we can maybe take that discussion 
after the above agreement?

about part one - both the RIR and LIR field can be set to zero's 
for direct assignment, for other they can go through RIR.

full text bellow:

--

---

From: Scott Leibrand <[email-masked]>
Date: Thu, 28 Jun 2007 16:25:06 -0700

Yes, I agree that any site should be able to get a ULA-C assignment, at 
nominal cost, and that ULA netblocks should be kept out of the DFZ.

-Scott

Roger Jorgensen wrote:
> people? I've read this through several times and I belive it satifsy 
> the following asked by "Templin, Fred L" <[email-masked]>
>
> about part one - both the RIR and LIR field can be set to zero's for 
> direct assignment, for other they can go through RIR.
>
>
>
>
> full text bellow:
>

---

From: james woodyatt <[email-masked]>
Date: Thu, 28 Jun 2007 16:54:21 -0700

> for direct assignment, for other they can go through RIR.

That's not how I read Mr. Vixie's proposed text.  If both RIR and LIR  
are zero, that implies a ULA prefix that IANA reserves for its own  
operations.  Any sites that want ULA-C prefixes without going to a  
RIR need to get one from a LIR explicitly numbered by IANA.  I don't  
think we've established any policy for how IANA is expected to assign  
LIR numbers for use when RIR=0.

---

From: Scott Leibrand <[email-masked]>
Date: Thu, 28 Jun 2007 17:08:50 -0700

james woodyatt wrote:
> operations.  Any sites that want ULA-C prefixes without going to a RIR 
> need to get one from a LIR explicitly numbered by IANA.  I don't think 
> we've established any policy for how IANA is expected to assign LIR 
> numbers for use when RIR=0.

Paul's text states, "For direct allocations by IANA, the value of zero 
(0x0000) is reserved."  To me, that's a pretty clear definition of which 
address space IANA would use for direct allocations or assignments to 
end users.

You're correct that we have not established any policy for how IANA 
would go about making such allocations or assignments.  I would suspect 
that they might elect not to do so, instead delegating that 
responsibility to the RIRs.  But if we did decide, as a matter of 
policy, that IANA should (also) make direct allocations and assignments, 
the proposed text defines space for that purpose.

-Scott

---

From: Mark Andrews <[email-masked]>
Date: Fri, 29 Jun 2007 11:43:21 +1000

> [email-masked]

	I believe 1 and 2 where always the intention.
	I believe you can't stop AAAA records for them being added.
	I believe that the reverse can be done but we need to take 
	care.
	I believe 4 can be achieved with the appropriate use of route
	filter and loose URPF over FC00/7.  Default null route for
	FC00/7 and appropritate route filters.
 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Fri, 29 Jun 2007 13:33:29 +1000

> is..."=20

	Well firstly these address will appear outside of IPv6 packets
	in environments where they will be automatically processed along
	with every other IPv6 address that is being processed.  The
	place that it processing the addresses may or may not be able
	to reach the ULA-C servers for the reverse lookup.

	It really should be up to the *user* of the ULA-C addresses
	to decide if they want to provide more than NXDOMAIN to
	interested parties on the Internet.  We shouldn't be
	arbitarially limiting functionality if it is technically
	possible to provide that functionality.

---

From: Jeroen Massar <[email-masked]>
Date: Fri, 29 Jun 2007 10:36:06 +0100

Roger Jorgensen wrote:
[..]
> too complicated and see bellow why.

How can something which already exists, and thus is not new, be "too
complicated"? Also as the text you referenced contained two different
approaches to the problem, which part is actually "too complicated" and
moreover why?

[..]
> THEIR side that give end-user direct request possibility without going

Direct assignments from IANA? They will be happy to do that. Of course,
the RIR's can be taken out of the equation completely, still don't call
the the fields "RIR Num" and "LIR Num" then as those are misnomers.

> This solution suite the need at my workplace perfect.

And how exactly does PI not suite that need?

[..]
> bad. Even with DNS in place it is acceptable for me personaly this way
> of doing it.

Thus first we try to actively fix a lot of things, and then to break
them all again? Very not useful and a lot of work down the drain.

> global reachable

Hold on, either it is LOCAL or it is GLOBAL, "not considered to be",
means that it is expected to be quite reachable on most parts on the
Internet.

As such, is the expectancy simply that fc00::/7 will become the new
addressing scheme overtaking all the RIR stuff that is in place already?

If that is what is wanted, then just specify that fc00::/7 will be used
for "Internet Part 2" which avoids RIRs and other such mechanisms. We
then at least have clarity what is trying to be accomplished with this
part of the address space.

> and if we just can as strong as possible make it clear
> global routing of this address space at all. No complicated text, keep
> it simple.

Endusers vote with their money. When a site is important enough to be
reached, they will go to an ISP that will have access to that site and
as such that space will be routed globally, the Internet will then
simply change to include the other spaces.

Greets,
 Jeroen

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 29 Jun 2007 12:13:30 +0200

On 2007-06-28 16:47, Paul Vixie wrote:
> where are those discussions being held, 

http://www1.ietf.org/mail-archive/web/ram/current/index.html
http://psg.com/lists/rrg/

> and can you post a summary,

Personally, no. The R&A Directorate is supposed to be
doing the overview and summary stuff:

http://www1.ietf.org/mail-archive/web/radir/current/index.html

> and why

I don't think it's preclusive. If that discussion does lead to an
architectural id/locator split, it will not override what we're discussing
here, IMHO. We'll still have IP addresses and they will still need to
be unambiguous. Also, that is a discussion that is finally happening
after ten years of needing to happen, so it's hardly surprising that
it hasn't converged rapidly.

> which unlike you i can feel forming.

I personally am not part of it then. I don't want to see any structured
allocation scheme; a robotic guarantee of uniqueness is all I want to see.
I don't want to facilitate making these things look like a binary
hierarchy, because that will cause people to believe for the next 50
years that they aggregate and are routeable. I also don't want to
accidentally create a business in selling large integers, which would
be the effect of structured registration as opposed to robotic random
numbers.

      Brian

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 29 Jun 2007 07:21:52 -0700

It should be obvious by now that my main purpose in these
discussions was to motivate a use case, and I consider my
"four questions" message as an unfortunate diversion from
that. A fifth question that should have been asked is:

  5) will it impair my use case?

and a sixth is:

  6) how can I be sure that it won't?

Fred

> From: Mark Andrews [mailto:[email-masked]] 
> Sent: Thursday, June 28, 2007 6:43 PM
> To: Templin, Fred L
> Cc: Paul Vixie; [email-masked]

---

From: Paul Vixie <[email-masked]>
Date: Fri, 29 Jun 2007 15:33:30 +0000

Brian E Carpenter <[email-masked]>:

> [vixie]
> > ... and why are we wasting our keystrokes discussing this if there's a
> > preclusive topic being discussed somewhere entirely else?
> 
> here, IMHO. We'll still have IP addresses and they will still need to be
> unambiguous. Also, that is a discussion that is finally happening after ten
> years of needing to happen, so it's hardly surprising that it hasn't
> converged rapidly.

ok.

> [vixie]
> > as proposed last night represent my understanding of a potential
> > consensus, which unlike you i can feel forming.
> 

i've been on the outside of ietf consensus more often than inside, so you've
got my sympathy if that matters.  also note, the fact that you don't agree
does not mean consensus isn't forming.  as to your specific concern, i'm
interested in knowing more about why you want the robotic guaranty of
uniqueness to be the only feature.  others here have made compelling cases
for a larger feature set for ULA-C, and yet you are unmoved.  your words...

> I don't want to facilitate making these things look like a binary hierarchy,
> because that will cause people to believe for the next 50 years that they
> aggregate and are routeable. I also don't want to accidentally create a
> business in selling large integers, which would be the effect of structured
> registration as opposed to robotic random numbers.

...involve a lot of unsupported predictions, and sound somewhat emotional.  i
don't think that we should deny others the features they're asking for on the
basis of what you don't want, especially since the things you say you don't
want aren't obviously inevitable, or obviously bad, to anybody else we've
heard from.  if you can make a compelling case for why these results are
inevitable AND why they would be bad, then you could win the elusive
"consensus" over to your side.  otherwise i think you're going to be on the
outside of this one.

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 29 Jun 2007 08:53:05 -0700

As of right now, I have a use case that (AFAICT) is
not yet fully-supported by functional specification.
So, IMHO it would be premature to turn over address
delegation authority at this time.

Fred

> Sent: Friday, June 29, 2007 8:34 AM
> To: [email-masked]

---

From: Paul Vixie <[email-masked]>
Date: Fri, 29 Jun 2007 15:57:29 +0000

> not yet fully-supported by functional specification.

which one?  AFAICT you're covered.

> delegation authority at this time.

then let's keep going.

---

From: bill fumerola <[email-masked]>
Date: Fri, 29 Jun 2007 13:36:45 -0700

> these are my comments on the following I-D:
[....]
>       | 7 bits |1|  8 bits  | 16 bits | 16 bits | 80 bits  |
[....]
>     limited to IN-ADDR.ARPA delegations and WHOIS records.

i think this is both an intelligent allocation strategy and am in favor
of this direction given to IANA. both good modifications.

-- bill

---

From: bill fumerola <[email-masked]>
Date: Fri, 29 Jun 2007 13:42:45 -0700

> 	possible to provide that functionality.

and this is the crux of my previous posts supporting reverse delegation
to a global unicast address. we want to provide all the possibilties
within the limit that it doesnt' interfere with Other People's Networks.

delegating reverse authority, including it in whois, allowing/including
them in radb networks are all flexible tools. no one says you have to
use them.

-- 
- bill fumerola / [email-masked]

---

From: Roger Jorgensen <[email-masked]>
Date: Fri, 29 Jun 2007 23:01:42 +0200 (CEST)

On Fri, 29 Jun 2007, Jeroen Massar wrote:
<snip>
> simply change to include the other spaces.

if that happen that user should be told very clear to change to either PI 
or PA type of UA addresses...

--

---

From: Scott Leibrand <[email-masked]>
Date: Fri, 29 Jun 2007 14:12:47 -0700

>> simply change to include the other spaces.

Jeroen,

Do you think that a site would try to connect to the Internet with 
*just* ULA addresses?  I would think that any responsible site operator 
would recognize that ULA addresses are not globally routable, and would 
give his global services PA or PI addresses as well.  In IPv6 it's easy 
to assign multiple IPs or subnets, so if I were a site using ULA-C 
addresses and wanted to offer services to the entire Internet, I would 
allocate my servers IPs from each of my providers' PA blocks for global 
reachability, and perhaps keep ULA-C for address consistency with my 
internal systems and that of any private partners I share ULA-C routes with.

-Scott