rfc1888.txt
来自「RFC 的详细文档！」· 文本 代码 · 共 900 行 · 第 1/3 页
TXT
900 行
or each Area must be limited to one physical subnet.
It is necessary in an IPv6 network that routes may be aggregated to
minimise the size of routing tables. If a subscriber is using both
normal IPv6 addresses [RFC1884] and restricted NSAPAs, these two
types of address will certainly not aggregate with each other, since
they differ from the second most significant bit onwards. This means
that there may be a significant operational penalty for using both
types of address with currently known routing technology.
4. Truncated NSAPA used as an IPv6 address
An NSAP address contains routing information (e.g. Routing Domain and
area/subnet identifiers) in the form of the Area Address (as defined
in [IS10589]). The format and length of this routing information are
typically compatible with a 16 byte IPv6 address, and may be
represented as such using the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0-3 |0 0 0 0 0 0 1 1| High order octets of full NSAP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4-7 | NSAP address continued |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8-11 | NSAP address continued |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
12-15| NSAP address truncated ... zero pads if necessary |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
If appropriate, when used as a destination IPv6 address, the
truncated NSAPA may be interpreted as an IPv6 anycast address. An
anycast address may be used to identify either an IPv6 node, or
potentially even an OSI End System or Intermediate System. For
Bound, et. al. Experimental [Page 6]
RFC 1888 OSI NSAPs and IPv6 August 1996
example, it might be configured to identify the endpoints of a CLNP
tunnel, or it might identify a particular OSI capable system in a
particular subnet.
If a truncated NSAPA is used as a source address, it must be
interpreted as a unicast address and must therefore be uniquely
assigned within the IPv6 address space.
If a truncated NSAPA is used as either the source or destination IPv6
address (or both), EITHER an NSAPA destination option OR an
encapsulated CLNP packet MUST be present. It is the responsibility of
the destination system to take the appropriate action for each IPv6
packet received (e.g. forward, decapsulate, discard) and, if
necessary, return to the originating host an appropriate ICMP error
message.
If the truncated NSAPA is used to identify a router, and an NSAPA
destination option is present, then it is the responsibility of that
router to forward the complete IPv6 packet to the appropriate host
based upon the Destination NSAP field in the NSAPA option. This
forwarding process may be based upon static routing information (i.e.
a manual mapping of NSAPs to IPv6 unicast addresses), or it may be
gathered in an automated fashion analogous to the ES-IS mechanism,
perhaps using extensions to the Neighbor Discovery protocol
[RFC1970]. The details of such a mechanism are beyond the scope of
this document.
This document does not restrict the formats of NSAP address that may
be used in truncated NSAPAs, but it is apparent that binary ICD or
DCC formats will be much easier to accomodate in an IPv6 routing
infrastructure than the other formats defined in [IS8348].
It is not expected that IPv6 autoconfiguration [RFC1971] and
discovery [RFC1970] will work unchanged for truncated NSAPAs.
Truncated NSAPAs are not meaningful within IPv6 routing headers, and
there is no way to include full NSAPAs in routing headers.
If a packet whose source address is a truncated NSAPA causes an ICMP
message to be returned for whatever reason, this ICMP message may be
discarded rather than being returned to the true source of the
packet.
Bound, et. al. Experimental [Page 7]
RFC 1888 OSI NSAPs and IPv6 August 1996
4.1 Routing truncated NSAPAs
This is a grey area. If the truncated NSAPA retains a hierarchical
structure, it can be routed like a restricted NSAPA, subject to the
same problem concerning the mismatch between Areas and subnets. If
possible, in the case of a GOSIP-like NSAPA, it should be truncated
immediately after the Area number. In this case the routing
considerations will be similar to those for restricted NSAPAs, except
that final delivery of the packet will depend on the last IPv6 router
being able to interpret the NSAPA destination option (or an
encapsulated CLNP packet).
In the general case, nothing can be said since the NSAPA could have
almost any format and might have very little hierarchical content
after truncation. There may be many cases in which truncated NSAPAs
cannot be routed across large regions of the IPv6 network.
The situation for route aggregation is similar to that described in
Section 3.1 as long as the truncated NSAPAs have ICD or DCC format.
However, if arbitrary NSAPAs are used nothing can be predicted about
route aggregation and we must assume that it will be poor.
Bound, et. al. Experimental [Page 8]
RFC 1888 OSI NSAPs and IPv6 August 1996
5. Carriage of full NSAPAs in IPv6 destination option
In the case of a truncated NSAPA used as an IPv6 address other than
for a CLNP tunnel, the full NSAPA must be carried in a destination
option. Any format defined in [IS8348] is allowed.
The NSAPA destination option is illustrated below. It has no
alignment requirement.
The option type code is 11-0-00011 = 195 decimal.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 0 0 0 0 1 1| Opt Data Len |Source NSAP Len| Dest. NSAP Len|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Source NSAP +
| |
+ +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Destination NSAP +
| |
+ +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The length fields are each one octet long and are expressed in
octets. The destination node should check the consistency of the
length fields (Option Data Length = Source NSAP Length + Dest. NSAP
Length +2). In case of inconsistency the destination node shall
discard the packet and send an ICMP Parameter Problem, Code 2,
message to the packet's source address, pointing to the Option Data
Length field.
The boundary between the source NSAP and the destination NSAP is
simply aligned on an octet boundary. With standard 20 octet NSAPs the
total option length is 44 bytes and the Option Data Length is 42.
Bound, et. al. Experimental [Page 9]
RFC 1888 OSI NSAPs and IPv6 August 1996
The NSAP encodings follow [IS8348] exactly.
If this option is used, both end systems concerned SHOULD use NSAP
addresses. In the exceptional case that only one of the end systems
uses NSAP addresses, the NSAP Length field of the other SHALL be set
to zero in the NSAP destination option.
This destination option is used in two cases. Firstly, an IPv6 source
node using normal IPv6 addresses (unicast address or anycast address)
MAY supply an NSAP destination option header for interpretation by
the IPv6 destination node. Secondly, an IPv6 node MAY use a truncated
NSAP address in place of a normal IPv6 address.
IPv6 nodes are not required to implement this option, except for
nodes using truncated NSAPAs other than for CLNP tunnels.
6. IPv6 addresses inside an NSAPA
If it is required, for whatever reason, to embed an IPv6 address
inside a 20-octet NSAP address, then the following format MUST be
used.
A specific possible use of this embedding is to express an IP address
within the ATM Forum address format. Another possible use would be
to allow CLNP packets that encapsulate IPv6 packets to be routed in a
CLNP network using the IPv6 address architecture. Several leading
bytes of the IPv6 address could be used as a CLNP routing prefix.
The first three octets are an IDP in binary format, using the AFI
code in the process of being allocated to the IANA. The AFI value
provisionally allocated is 35, but this requires a formal
modification to [IS8348]. The encoding format is as for AFI value 47
[IS8348]. The third octet of the IDP is known as the ICP (Internet
Code Point) and its value must be zero. All other values are reserved
for allocation by the IANA.
Thus an AFI value of 35 with an ICP value of zero means that "this
NSAPA embeds a 16 byte IPv6 address".
The last octet is a selector. To maintain compatibility with both
NSAP format and IPv6 addressing, this octet must be present, but it
has no significance for IPv6. Its default value is zero.
Bound, et. al. Experimental [Page 10]
RFC 1888 OSI NSAPs and IPv6 August 1996
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0-3 | AFI = 35 | ICP = 0000 | IPv6 (byte 0)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4-7 | IPv6 (bytes 1-4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8-11 | IPv6 (bytes 5-8) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
12-15| IPv6 (bytes 9-12) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
16-19| IPv6 (bytes 13-15) |0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Theoretically this format would allow recursive address embedding.
However, this is considered dangerous since it might lead to routing
table anomalies or to loops (compare [RFC1326]). Thus embedded IPv6
address MUST NOT have the prefixes 0x02 or 0x03, and an NSAPA with
the IANA AFI code MUST NOT be embedded in an IPv6 header.
An NSAPA with the IANA AFI code and ICP set to zero is converted to
an IPv6 address by stripping off the first three and the twentieth
octets. All other formats of NSAPA are handled according to the
previous Chapters of this document.
7. Security Considerations
Security issues are not specifically addressed in this document, but
it is compatible with the IPv6 security mechanisms [RFC1825].
Acknowledgements
The authors are pleased to acknowledge the suggestions and comments
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?