Subject: Re: W.G. Last Call on "IP Version 6 Addressing Architecture"

From: Erik Nordmark <[email-masked]>
Date: Fri, 7 Sep 2001 09:39:05 +0200 (CEST)

> I also think that abolishing the term "format prefix" is obfuscation. The
> fact is that the leading bits of an address *are* a format prefix and
> implementors *will* look at those bits before processing an address. Why
> obscure that fact?

Brian,
It is exactly this that we want to avoid - implementors thinking that they
need to inspect the first 3 bits of the addresses.
There is no need to do this and we need to reduce the probability that
implementors hard-code any knowledge of any leading 3 bit combinations
since it will make it harder to use the other 15/16th of the address space
in the future.

  Erik

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 07 Sep 2001 13:49:17 -0500

Well, I miswrote slightly - the fact is that an implementation has to
first check if the address is any of the non-global-unicast cases, and that
involves doing a sequence of matches which involve the bits
Formerly Known as the Format Prefix (not just 3 of them of course). 
I think the new text makes this harder to understand. It doesn't change
what implementors should do.

Feel free to ignore my comment if nobody else has the same reaction.

   Brian

---

From: Matt Crawford <[email-masked]>
Date: Fri, 07 Sep 2001 14:44:41 -0500

> Feel free to ignore my comment if nobody else has the same reaction.

I, for one, do not have the same reaction.

---

From: Alex Conta <[email-masked]>
Date: Fri, 14 Sep 2001 11:36:28 -0400

While I think an implementation does not have to explicitly be concerned
about Prefix Format bits, since the bits are automatically included in a
prefix, I am quite concerned about the fact that at this moment the
entire IPv6 space is 
allocated, with no experimental, or reserved space for future
development.

Carving out such a space ahead of time, like in IPv4, worked well. It
provides the benefit that if people experiment with a number of
addresses, they know ahead of time, what they have available, and will
not conflict with global addresses, or other addresses, already 
in use.

Carving out space at a later time, experience showed, is a difficult
thing to do, it is controversial, and the effort to standardize such an
address block allocation may hamper the essential part of the work,
which needs the address block. Additionally, when would one
ask for such address space? when a projects starts, when is well
underway? The model is quite questionable.

Alex

---

From: Randy Bush <[email-masked]>
Date: Fri, 14 Sep 2001 11:49:28 -0400

> I am quite concerned about the fact that at this moment the entire
> IPv6 space is allocated, with no experimental, or reserved space for
> future development.

i don't perceive that this is at all the case.

almost no space has been allocated, O(100) /35s.

the current drafts have iana considerations asking that they only
allocate from 001/3.

what am i missing here

randy

---

From: Alex Conta <[email-masked]>
Date: Fri, 14 Sep 2001 14:37:25 -0400

Obviously, there was, and is confusion: 

a. 
My wording "allocated" refers to the specifications'
allocation/partioning, as opposed to registries' allocation. Sorry.

b.
Comparing  section 2.4 of RFC 2373 (page 6), and the draft (page 7),
there is difference, since a table was removed/moved. Based on page 7 of
the draft, the table in section 
2.4 seem to suggest that the "global unicast" is "(everything else)",
besides, 
unspecified, loopback, multicast, link-local, and site-local addresses.
These were both
a source of confusion.

c.
Why is the IANA Section in the Appendix C, following two informational
appendices? It is not "normative"? Given the place and the order, one
can simply miss it, as I did, sorry, which can be an obvious source of
confusion. 

I think the specifications being more clear, would help lower the
probability of confusion, in particular, information relative to the
partitioning of the address space.
Also the partitioning must be normative, or I am missing something

Alex

---

From: Randy Bush <[email-masked]>
Date: Fri, 14 Sep 2001 14:42:56 -0400

> I think the specifications being more clear

send text

randy

---

From: Alex Conta <[email-masked]>
Date: Fri, 14 Sep 2001 15:47:23 -0400

OK, since you've asked, here is an example -- please note that having a
separate section
which eliminates the confusion between "representation" and
"partitioning" would IMHO add clarity:

----------

X.Y.  Address Space Partitioning 

The IPv6 address space is partitioned to provide an adequate number of
addresses for various types of communications, such as unicast,
multicast, and/or anycast. The partitioning provides also an adequate
number of addresses for experimental, and/or future use. 

Currently the following space is partitioned and assigned for:

 IPv6 unicast:
	
1/1024 (2**118 = 332306998946228968225951765070086000 addresses) of the
total space is              assigned for link-local communications
1/1024 (2**118 = 332306998946228968225951765070086000 addresses) of the
total space is             assigned for site-local communications

 1/8  (2**125 = 4.2535295865117307932921825928971e+37 addresses) of the
total space is            assigned for global unicast communications

note: anycast communications used unicast address space

 IPv6 multicast:

1/256 (2**120 = 1.3292279957849158729038070602803e+36 addresses) of the
total space is             assigned for multicast communications

 RFC 1888:

1/128 (2**121 = 2.6584559915698317458076141205607e+36 addresses) of the
total space is 
        assigned for RFC 1888 type communications

This represents 1/8+7/512 of the total IPv6 address space.

  Unassigned:

  6/8 + 57/512 (2.5521177519070384759753095557382e+38
+                                 3.788299787987010237775850121799e+37
of addresses) 
               This is the remaining of the address space, which has not
been assigned.
            
Note: specifying real numbers along with fractions adds a good
indication of the dimensions of the address space.

--------

---

From: Randy Bush <[email-masked]>
Date: Fri, 14 Sep 2001 15:51:49 -0400

>                This is the remaining of the address space, which has not

sorry, i should have been more specific.  please send CORRECT text :-).

that space is unicast space.  we specifically don't want folk coding
forwarding or routing algorithms treating it any differently than

>  IPv6 unicast:

we've been to that movie, and even the popcorn sucked.  took years to clean
stuff up.

randy

---

From: Alex Conta <[email-masked]>
Date: Fri, 14 Sep 2001 16:37:20 -0400

> forwarding or routing algorithms treating it any differently than

So "unassigned" means really "assigned for unicast, but undefined yet
type of addresses".

That would certainly not represent accurately or encourage any future
developments other than the one focused on unicast. How could we know
now what the future communication models would be? Furthermore, I do not
see the motivation behind such restriction.

Could you elaborate on the exact reasons?

---

From: Randy Bush <[email-masked]>
Date: Fri, 14 Sep 2001 16:50:27 -0400

> Could you elaborate on the exact reasons?

because we remember implementations and protocols that had A, B, and C hard
coded and how hard it was getting cidr deployed.

we want to make it very clear that current/new implementations should treat
it all as unicast.

if someone comes up with some bright idea down the pike, then is the time to
hack.  but we should not set things up so we have to hack to achieve what we
see as the most probably path today.

make sense?

randy

---

From: Thomas Narten <[email-masked]>
Date: Fri, 14 Sep 2001 17:02:40 -0400

Brian,

> Formerly Known as the Format Prefix (not just 3 of them of course).

The key here is that implementations need to check for a list of
prefixes that they special case. None of them (at the present time)
are just the first 3 bits. So they shouldn't check the format prefix
per se.

Having a format prefix doesn't actually help in the overall scheme. If
at some point someone wants to reserve a swath of address space for
some special/experimental purpose (e.g., 8+8, etc.), that can be done
by simply reserving a specific prefix that is big enough to meet the
need. Moreover, that prefix may be quite a bit smaller than a /3,
which is what an FP is. 

So, IMO, actually removing the FP from the document is a reasonable
approach. If there is no FP, implementations won't make the mistake of
looking at just those bits and doing the wrong thing.

[Note: whether the current text is adequately clear on all this is
something I haven't checked. My comments are on the rational for not
having an FP.]

Thomas

---

From: Thomas Narten <[email-masked]>
Date: Fri, 14 Sep 2001 17:17:11 -0400

> While I think an implementation does not have to explicitly be
> concerned about Prefix Format bits, since the bits are automatically
> included in a prefix, I am quite concerned about the fact that at
> this moment the entire IPv6 space is allocated, with no
> experimental, or reserved space for future development.

"allocated" is probably the wrong word. "assigned (and in use)" is
what I think is important.  Once a swath of address space is assigned
(and used) for some purpose, it's hard to take it back for some other
use.

The current ID defines some ranges of address for special purposes,
but says the rest should be treated (from an implementation
perspective) as global unicast. I.e., treat them all the same.

If, at some future point, someone wants to experiment and needs a
range of address that it will treat "differently", all that needs to
happen is that it obtain a big enough range of addresses for its
purpose. As long as there is such a range of addresses that is not in
use by anyone, this isn't a problem.

As Randy has pointed out, the IANA considerations section in the ID
makes it clear that only 1/8th of the available space is being made
available for usage and assignment. So we still have lots of space to
use differently, should someone make the case that we need to.

> not conflict with global addresses, or other addresses, already 

Actually, reserving an experimental range in advance, is not the best
way to do it. You might reserve too much or too little. Hard to tell
in advance what the future will bring. The better approach is to
assign address space for use in a way that allows one to put off for
as long as possible making the decision on how big a range to reserve
for one purpose vs. another. Leave things flexible for a future that
is hard to predict.

Thomas

---

From: Alex Conta <[email-masked]>
Date: Fri, 14 Sep 2001 18:56:47 -0400

Thomas Narten wrote:

> [...]

OK. Your clarification is useful, since this is really what I had in
mind. 
Perhaps the text in the draft could be made more clear - something
closer to 
yours.

> [..]

Two comments relative to this - already made earlier.

a.
Since I missed the earlier opportunity, I am bringing this feedback now,
sorry. 
I would have been happier if the clarification was up front, like having
a section on address space partitioning, like I suggested in some text
sent earlier, or some text at 
the beginning in the IANA section, rather than some text in a
"foot-note".

b.
The IANA considerations text is in Appendix C, after 2 informational
appendices. 
Shouldn't the section be "normative", and part of  the main document,
rather than an appendix ?

> in advance what the future will bring.

I am not talking about a large chunk. A tiny space can always be
extended, if someone needs bigger space, for a new thing, which seems
more than just an experiment, or it can ask for a separate new
assignment. Having that tiny space ahead of time, saves the time of
going and asking for it, in particular for temporary experiments, kind
of like what D, and  E, where in IPv4.... The effort of getting an
assignment should take place only if the assignment is
(quasi-)permanent. This is my opinion, based on past and current
experience. 

> [..]

Alex

---

From: Alex Conta <[email-masked]>
Date: Fri, 14 Sep 2001 19:00:35 -0400

> coded and how hard it was getting cidr deployed.

Thanks. Yours and Thomas's were useful clarifications.

---

From: [email-masked]
Date: Sat, 15 Sep 2001 08:54:39 +0900

>>                This is the remaining of the address space, which has not

	for implementers, it needs to be known that the unassigned region is
	unicast addresses, not just "unassigned".
	otherwise, implemnters cannot implement the code to handle these
	"future allocation" addresses.  in my understanding this is the
	main reason for the wording change between RFC and i-d.

itojun

---

From: "Chae-yong Chong" <[email-masked]>
Date: Mon, 17 Sep 2001 15:53:53 +0900

Hi

When I read a draft "An overview of the introduction of IPv6 in the internet" 
I got some ambigous statement in 4.1.3

4.1.3 Tunnel Broker
...

IPv4 address requirements : 1
...

What does that "1" means? Does that mean Tunnel Broker's IPv4 address?
In other section, there always some more description like "1 per host" or ">=1 per site"

In my understanding that should be corrected like "1 per host".

Chae-yong

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 17 Sep 2001 15:03:47 -0500

Thomas Narten wrote:
...
> need. Moreover, that prefix may be quite a bit smaller than a /3,

Actually the former FP was clearly a variable length object. Anyway,
I read you to mean that chopping out a large fraction of the global
unicast space for son-of-8+8 is an option left open by this
architecture. That's fine, as long as people realise that such addresses
would contain mutable bits, with impact on checksum algorithms.

   Brian

---

From: Thomas Narten <[email-masked]>
Date: Mon, 17 Sep 2001 16:40:05 -0400

Brian E Carpenter <[email-masked]> writes:

> architecture.

Yes. If someone comes along and makes a case that some chunk of
address space needs to be reserved for a specific purpose other than
global unicast addresses, that request would be evaluated on its
merits when it is made.

> That's fine, as long as people realise that such addresses would
> contain mutable bits, with impact on checksum algorithms.

Perhaps. :-) I.e., any proposal to reserve some swath of address space
for some new purpose would presumably also explain how the space will
be used, how nodes implementing the new service interact with devices
that don't understand the new usage (if they need to), etc.

Thomas

---

From: Thomas Narten <[email-masked]>
Date: Mon, 17 Sep 2001 16:44:45 -0400

> b.  The IANA considerations text is in Appendix C, after 2
> informational appendices.  Shouldn't the section be "normative", and
> part of the main document, rather than an appendix ?

I'm not sure I agree with this assessment. I.e., all of the text in
the document is normative, unless there is a specific disclaimer.

I agree that most documents seem to put the IANA considerations
section as a section near the end of the document (rather than in an
Appendix), but that doesn't mean that the section is non-normative.

> extended,

Actually, it can't always. I.e., if the space needs to be extended in
a way (for example) that aggregates, that only works if the adjacent
space is still unallocated at the time the extension is needed.

Thomas