Subject: I-D ACTION:draft-ietf-ipv6-unicast-aggr-v2-02.txt

From: [email-masked]
Date: Tue, 04 Mar 2003 07:28:42 -0500

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		: IPv6 Global Unicast Address Format
	Author(s)	: R. Hinden, S. Deering
	Filename	: draft-ietf-ipv6-unicast-aggr-v2-02.txt
	Pages		: 5
	Date		: 2003-3-3
	
RFC2374 'An IPv6 Aggregatable Global Unicast Address Format' defined
an IPv6 address allocation structure that includes TLA (Top Level
Aggregator) and NLA (Next Level Aggregator).  This document replaces
RFC2374, and makes RFC 2374 and the TLA/NLA structure historic.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-unicast-aggr-v2-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-unicast-aggr-v2-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.

---

From: Bob Hinden <[email-masked]>
Date: Tue, 04 Mar 2003 10:58:21 -0800

I think the new draft resolves issues raised during the last call.  Changes 
to the document include:

  - Generalize the scope of the document to cover more than the 2000::/3
    prefix.  This includes changing the title and introduction text.
  - Added a new section that describes in more detail why the TLA/NLA structure
    is being made historic.
  - Including an example of the address format that is consistent with
    the recommendations in RFC3177.
  - Added Erik Nordmark as an author (note this is not shown in the
    ID announcement).
  - Clarified normative and non-normative references.
  - Various small improvements to the text.

I think the consensus of the discussion was to advance this document as in 
Informational RFC instead of to Proposed Standard.  I believe it is now 
ready to be sent to the IESG.

Bob

At 04:28 AM 3/4/2003, [email-masked] wrote:
>Content-Type: text/plain
>Content-ID:     <[email-masked]>
>
>ENCODING mime
>FILE /internet-drafts/draft-ietf-ipv6-unicast-aggr-v2-02.txt
>
><ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipv6-unicast-aggr-v2-02.txt>

--------------------------------------------------------------------
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: Pekka Savola <[email-masked]>
Date: Tue, 4 Mar 2003 21:30:11 +0200 (EET)

> ready to be sent to the IESG.

One substantial point I'd like to see more discussion on is whether folks
feel that "Address Format" section, mainly restating what addr-arch-v3-11
says on 64 bit IID's, seems like the right thing to do in this document?

I think this point was brought up by at least Thomas Narten and others, 
but I don't remember whether a closure was reached.

So, I believe everything starting from:

   [ARCH] also requires that all unicast addresses, except those that
   start with binary value 000, have Interface IDs that are 64 bits long
   and to be constructed in Modified EUI-64 format.  The format of
   global unicast address in this case is:
[...]

should be removed, if not the whole section.

I can live with this but IMO putting 64-bit-interface-ID thing which is 
rather controversial still in too many documents seems like something to 
be careful about.

How do others feel?

Below are a few very minor editorial nits:

INTERNET-DRAFT                                         R. Hinden, Nokia
February 26, 2003                                     S. Deering, Cisco
                                                       E. Nordmark, Sun

==> the header should probably say IPv6 working group.

   unassigned parts of the IPv6 address space to the purpose of Global
   Unicast as well.

==> "to the purpose of" ?  Sounds awkward, especially "to"?
==> "Global Unicast" capitalized looks funny, as if it was somehow a 
special term.

   Non-Normative

==> better named Informative, I guess?

   [ARCH]    Hinden, R., "IP Version 6 Addressing Architecture",
             Internet Draft, <draft-ietf-ipngwg-addr-arch-v3-11.txt>,
             October 2002.

==> Forgot Steve from the author list :-)

6.0 Security Considerations

==> I believe Sec Cons is typically up, before references but YMMV.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Quality Quorum <[email-masked]>
Date: Tue, 4 Mar 2003 19:01:57 -0500

> rather controversial still in too many documents seems like something to

The problem here is software implementation of longest prefix match.
Up to this point it was limited to a few TLAs with 48 bits which was
quite  doable in software, this draft expands it to 61 and you are
proposing 125, which is well beyond capabilities of software based
lookups.

I do not see anything specifically wrong with this approach if a complete
enterprise router replacement is a stated goal of IPv6. If not then we
have to address the issue of software based implementations somehow.

Again, it may be a way to go, but frankly I am in a little shock -
after many years of planing for various hierarchical partitions to find
myself back in CIDR without borders environment and all of it in a matter
of days.

> Pekka Savola                 "You each name yourselves king, yet the

Thanks,

Aleksey

---

From: Pekka Savola <[email-masked]>
Date: Wed, 5 Mar 2003 06:25:16 +0200 (EET)

On Tue, 4 Mar 2003, Quality Quorum wrote:
> quite  doable in software, this draft expands it to 61 

Note that "this" draft does not do it, it has been already done in
addr-arch-v3, which has been approved by IESG/IAB for publication to
Proposed Standard.

> and you are

"well beyond capabilities of software based lookups" seems to be clearly 
false: I've run IPv6 test on Linux / BSD-based systems, which do have 
exactly that and have obtained gigabit-grade results, the same as 
with IPv4.

Perhaps that applies in a very specific scenario of sw lookups only.

Btw, it's 64 and 128, respectively: you seem to be doing exactly what's 
forbidden, glueing 2000::/3 in the implementation -- or do you do 
48/64/128-bit lookup for non-2000::/3 routes?

---

From: Quality Quorum <[email-masked]>
Date: Wed, 5 Mar 2003 10:28:52 -0500

> addr-arch-v3, which has been approved by IESG/IAB for publication to

Then we had a bunch of RFCs specifying various allocation schemes which
effectively paired it down to 48 bit (in some instances 39 bit) longest
prefix match.

> Perhaps that applies in a very specific scenario of sw lookups only.

The real life requirement for a low cost router is OC-48 with 40-byte
frames, which is about half order of magnitude above hardware limitations
of PCI bus.

> 48/64/128-bit lookup for non-2000::/3 routes?

It is way easier that that, roughly speaking first you do classification
and then you do longest prefix match (if you are in the right TLA or in
site local), or hash table lookup (if you are in multicast), or drop.

The key word is "software", so it could be easily adapted to non-tectonic
changes.

Again, the things you are proposing may be a way to go (personally I
would love to see every enterprise router to be replaced), however,
I suppose that you have to clearly understand consequences of
your proposal.

It seems to me that, if total router replacement is not the goal, we have
to establish at least some transitional period guarantees - say address
assignment policies of the next 20 years would guarantee a right of
existence for software implementations.

Thanks,

Aleksey

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 05 Mar 2003 11:09:29 +0100

below...

> myself back in CIDR without borders environment and all of it in a matter

I find this surprising. The decision to scrap TLA/NLA was taken
a long time ago, and in any case it's always been clear that
such boundaries were not architectural, but merely conventions
in the address assignment scheme. So any implementation that takes
any notice of TLA/NLA was broken anyway. The only boundary that
should affect code is the /64 boundary, which is why the paragraph
that Pekka cited is valuable.

  Brian

---

From: Quality Quorum <[email-masked]>
Date: Wed, 5 Mar 2003 11:10:17 -0500

> in the address assignment scheme.

I would say existence of thses conventions (I am talking about TLA) made
incoming transition to v6 a way more feasible.

> So any implementation that takes any notice of TLA/NLA was broken
> anyway. The only boundary that

I suppose 125-bit LPM will significantly slow down acceptance of ipv6.

I suppose that v6 will benefit from administrative steps setting
limits on LPM, at least for transitional period.

Thanks,

Aleksey

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 05 Mar 2003 18:00:34 +0100

> limits on LPM, at least for transitional period.

I'd agree, that is why the /64 boundary is so important.

   Brian

---

From: Quality Quorum <[email-masked]>
Date: Wed, 5 Mar 2003 12:14:26 -0500

> I'd agree, that is why the /64 boundary is so important.

Glad to hear it.

I would say that 61-bit LPM while doable is pretty steep for software
still.

Can we have say allocation policy for transition limiting it to lower
number ?

Thanks,

Aelksey