As per Relevance of the word copyright, we have this rfc below:
Network Working Group B.
Request for Comments: 2921
Category: Informational September 2000
6BONE pTLA and pNLA Formats (pTLA
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited
Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
This memo defines how the 6bone uses the 3FFE::/16 IPv6
prefix, allocated in RFC 2471, "IPv6 Testing Address Allocation",
[6BONE-TLA], to create pseudo Top-Level Aggregation
(pTLA's) and pseudo Next-Level Aggregation Identifiers (pNLA's).
The address formats here are contributions of various
participants of the 6bone testbed project, and of the IPng
NGtrans IETF working groups
Table of
1. Introduction................................................. 1
2. 6BONE pTLA/pNLA Format....................................... 2
3. Security Considerations...................................... 6
References....................................................... 6
Author's Address................................................. 6
Full Copyright Statement......................................... 7
1.
This memo defines how the 6bone uses the 3FFE::/16 IPv6
prefix, allocated in RFC 2471 [6BONE-TLA], to create pseudo Top-
Aggregation Identifiers (pTLA) and pseudo Next-Level
Identifiers (pNLA).
Fink Informational [Page 1]
RFC 2921 6BONE pTLA and pNLA Formats September 2000
The guiding specifications for IPv6 addressing relating to the 6
prefix, and the pTLA and pNLA formats, are "IP Version 6
Architecture" [ADDRARCH], and "An IPv6 Aggregatable Global
Address Format" [AGGR].
The purpose of creating pseudo TLA and NLA formats for the 6bone
to provide a prototype of the actual TLA and NLA formats as
might be used in production IPv6 networks. To do this economically
using only a minimum of real production IPv6 address space, a
TLA, 3FFE::/16, was reserved by the IANA (Internet Assigned
Authority) for testing on the 6bone. Thus it was necessary to
a pretend-to-be, or pseudo, TLA and NLA structure to use under
3FFE::/16 prefix
Given the 48-bit length of the IPv6 Aggregatable Global
Address external routing prefix (that contains the TLA and
identifiers), there is enough room to extend the TLA ID to contain
pTLA and shorten the NLA ID to become a pNLA. This document
this
In early 1999, it was decided to change the 6bone's pTLA format
allow greater expansion of the testbed network, thus
more than the original 256 pTLA-s. Thus there are now two 6bone
and pNLA formats. This document specifies this
2. 6BONE pTLA and pNLA
2.1 Original 8-bit pTLA and 24-bit pNLA
The original pTLA and pNLA format was intended to accommodate 256
pTLA-s, i.e., backbone networks carrying IPv6 transit traffic
The original TLA and NLA ID-s as specified in [AGGR] are as follows
| 3 | 13 | 32 | 16 | 64 bits |
+---+-----+---------------------+--------+-----------------+
|001| TLA | NLA ID | SLA ID | Interface ID |
+---+-----+---------------------+--------+-----------------+
The TLA value 1FFE was assigned to the 6bone, which when viewed
the 3-bit format prefix in prefix notation form is 3FFE::/16.
The first 8-bits of the NLA ID space are assigned as the pTLA
defines the top level of aggregation (backbone) for the 6bone.
provides for 256 6bone backbone networks, or pTLA-s, and leaves
24-bit pNLA ID for each pTLA to assign as needed
Fink Informational [Page 2]
RFC 2921 6BONE pTLA and pNLA Formats September 2000
| 16 | 8 | 24 | 16 | 64 bits |
+-+---------+-----+-------------+--------+-----------------+
| 0x3FFE |pTLA | pNLA | SLA ID | Interface ID |
+-+---------+-----+-------------+--------+-----------------+
In prefix notation form the pTLA is 3FFE:nn00::/24, where nn is
pTLA assignment
The remaining NLA ID space can be used by each pTLA for
downward aggregated delegation
| n | 24-n bits | 16 | 64 bits |
+-----+--------------------+--------+-----------------+
|pNLA1| Site | SLA ID | Interface ID |
+-----+--------------------+--------+-----------------+
| m | 24-n-m | 16 | 64 bits |
+-----+--------------+--------+-----------------+
|pNLA2| Site | SLA ID | Interface ID |
+-----+--------------+--------+-----------------+
| o |24-n-m-o| 16 | 64 bits |
+-----+--------+--------+-----------------+
|pNLA3| Site | SLA ID | Interface ID |
+-----+--------+--------+-----------------+
The pNLA delegation works in the same manner as specified in [AGGR].
pTLA's are required to assume registry duties for the pNLA's
them, pNLA1's for those below them, etc
2.2 New 12-bit pTLA and 20-bit pNLA
After it became clear that the 6bone would become a useful
for transition, in addition to its early role as a testbed
specifications and implementations, the 6bone community decided
expand the size of the pTLA ID
Several important decisions regarding this expansion of the
field are
1. to leave the currently allocated 8-bit pTLA-s in use until
space was needed, thus relying on a range value check to
the new pTLA format
2. to use a modulo 4-bit sized pTLA ID to make reverse path
into the DNS easier
Fink Informational [Page 3]
RFC 2921 6BONE pTLA and pNLA Formats September 2000
3. given 2. above, to keep the pTLA ID size as small as
to not restrict pNLA ID size
Therefore, the first 12-bits of the NLA ID space are assigned as
pTLA that defines the top level of aggegation (backbone) for
6bone. This would eventually provide for 4096 6bone
networks, or pTLA-s, and leaves a 20-bit pNLA ID for each pTLA
assign as needed
| 16 | 12 | 20 | 16 | 64 bits |
+-+---------+-------+-----------+--------+-----------------+
| 0x3FFE | pTLA | pNLA | SLA ID | Interface ID |
+-+---------+-------+-----------+--------+-----------------+
In prefix notation form the pTLA is 3FFE:nnn0::/28, where nnn is
pTLA assignment. However, as the existing 8-bit pTLA's are being
in use for the present, the nnn value starts at 0x800 for now,
yielding only 2048 pTLA's in this new format
The remaining NLA ID space can be used by each pTLA for
downward aggregated delegation
| n | 20-n bits | 16 | 64 bits |
+-----+--------------------+--------+-----------------+
|pNLA1| Site | SLA ID | Interface ID |
+-----+--------------------+--------+-----------------+
| m | 20-n-m | 16 | 64 bits |
+-----+--------------+--------+-----------------+
|pNLA2| Site | SLA ID | Interface ID |
+-----+--------------+--------+-----------------+
| o |20-n-m-o| 16 | 64 bits |
+-----+--------+--------+-----------------+
|pNLA3| Site | SLA ID | Interface ID |
+-----+--------+--------+-----------------+
As with the original pTLA format, the pNLA delegation works in
same manner as specified in [AGGR]. pTLA's are required to
registry duties for the pNLA's below them, pNLA1's for those
them, etc
2.3 Example Format For pNLA'
An example usage of the pNLA space is given to demonstrate what
reasonable and possible. It should not be assumed that this
the pNLA space must be used this way. As the new pTLA and pNLA
is now the default, the example here assumes the 20-bit pNLA format
Fink Informational [Page 4]
RFC 2921 6BONE pTLA and pNLA Formats September 2000
The following example provides for up to 255 intermediate
ISP's (called pNLA1 below). The pNLA1 value of zero is meant
indicate that there is no intermediate transit ISP between
backbone pTLA network and the end user site
|<-----20-bit pNLA ID----->|
| |
| 8 | 12 bits | 16 | 64 bits |
+-----+--------------------+--------+-----------------+
|pNLA1| Site ID | SLA ID | Interface ID |
+-----+--------------------+--------+-----------------+
Intermediate transit networks (pNLA1's) would assign uniques
ID's for eachend user site served
As an example of this, assuming a backbone pTLA of 0x800,
intermediate transit ISP (thus a pNLA1 of 0x00) and a sequential
ID (with start at the right edge numbering) of 0x0001, the
prefix for the first site would look like
3FFE:8000:0001/48
6bone _|||| |||| ||||___
|||| |
b/b site____|||| |
| |
transit________|_|
Another example of this usage, assuming the same backbone pTLA1
0x800 and an intermediate transit ISP under it (numbering from
left edge) with an NLA1 of 0x80, and a sequential site ID of 0x0001,
the routing prefix for the first site connected would look like
3FFE:0180:0001/48
6bone _|||| |||| ||||___
||||
b/b site____||||
||
transit_______||
Note 1: the two sites numbered 0x001 in the above examples are
two different sites as their pNLA1 authority above them is
(i.e., in the first case no transit exists thus the site is
connected to the pTLA backbone ISP, and in the second case the
is directly connected to intermediate transit ISP 0x80).
Note 2: there would be nothing to prevent an pNLA1 transit site
further allocating pNLA's below, but that becomes the policy of
pTLA and pNLA's above them to work out
Fink Informational [Page 5]
RFC 2921 6BONE pTLA and pNLA Formats September 2000
Note 3: The 6bone registry, which is a RIPE-style database
documenting IPv6 sites connected to the 6bone, has an "inet6num
object to allow documentation of all IPv6 addresses allocated
3. Security
IPv6 addressing documents do not have any direct impact on
infrastructure security
[ADDRARCH] Hinden, R. and S. Deering, "IP Version 6
Architecture", RFC 2373, July 1998.
[AGGR] Hinden, R., O'Dell, M. and S. Deering, "An IPv
Aggregatable Global Unicast Address Format", RFC 2374,
July 1998.
[HARDEN] Rockell, R. and R. Fink, "6Bone Backbone
Guidelines", RFC 2772, February 2000.
[KEYWORDS] Bradner, S., "Key words for use in RFCs to
Requirement Levels", BCP 14, RFC 2119, March 1997.
[6BONE-TLA] Hinden, R., Fink, R. and J. Postel, "IPv6 Testing
Allocation", RFC 2471, December 1998.
Author's
Bob Fink,
Lawrence Berkeley National
MS 50A-3111
1 Cyclotron
Berkeley, CA 94720
Phone: +1 510 486 5692
Fax: +1 510 486 4790
EMail: fink@es.
Fink Informational [Page 6]
RFC 2921 6BONE pTLA and pNLA Formats September 2000
Full Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Fink Informational [Page 7]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
