Next Generation and OSI BOF (NOSI)
Reported by Ross Callon/Bay Networks and Brian Carpenter/CERN
About 35 people attended this BOF, chaired by Brian Carpenter.
In the IPv6 base document, and in discussions in the Toronto IETF, it
was suggested that it would be useful to be able to map NSAP addresses
into IPv6 addresses. This appears to be related to CLNP to IPv6
transition. However, there is no consensus on whether the IETF needs to
do anything in this space (for example, work might be done in ISO
instead). We need to understand the requirements first, then consider
work items, and where (what group) they should be done.
Thus, the agenda for this BOF:
o Agree on general OSI to IPv6 conversion requirements
o Agree on major network layer scenarios
o Identify useful mechanisms and hear from their proponents
SC6 (ISO/IEC JTC1/SC6) presumably has an issue, regarding whether to
continue work on CLNP. We might want to consider (as individuals) giving
some ideas to them. Note that Jack Houldsworth was present in the BOF
as ISO liaison. DEC is also planning support for customers using DECNET
Phase V (using CLNP) to use DECnet over IP -- we would like to
understand from the DEC folks how this is being done.
Question from the floor: What is the forum for experimental work on OSI
applications over the Internet? Nobody had an answer.
Brian Carpenter presented conversion requirements:
o R1. Existing CLNP networks want to migrate to TP4 over IPv6
o R2. Existing CLNP network wants to migrate to Internet
applications over IPv6
o R3. Planned CLNP net changes plan to instead go to TP4 over IPv6
o R4. Planned CLNP network change their plan to instead to Internet
application over IPv6
o R5. TP0/CONS net wants to migrate to TP0 over IPv6
o R6. (Are there others?)
It was pointed out that the ``TP4'' and ``TP0'' in above requirements
should really say ``OSI applications.'' Customers do not care which
transport layer protocol is being used. The API over the transport
layer may need to stay the same. It was also pointed out that the above
requirements are not mutually exclusive; they just show the range of
possibilities.
Brian then gave four possible scenarios for the network layer:
o Proposal 1: The final goal is a pure IPv6 network with pure IPv6
addresses, with no trace of CLNP nor NSAPs.
+ Simple end scenario.
- CLNP investment lost.
(This last point is controversial; some knowledge may be
maintained, and the knowledge that is maintained may be the
bulk of the retrievable investment.)
o Proposal 2: Final goal is an IPv6 network in which some hosts have
NSAP addresses.
+ (?) NSAP addressing plans preserved.
(This alleged advantage was vigorously debated, with some folks
feeling that there is no significant advantage either way, in
that the bulk of the effort can be used even if the exact 20
byte addresses are not). -- Extra complexity in hosts and
routers.
- Two address plans connected only by IDRP.
(It was politely pointed out that this is bogus.)
- No CLNP service despite having OSI addresses.
o Proposal 3: Final goal is a pure IPv6 network with a pure IPv6
addressing and routing, but NSAP addresses are transported
end-to-end as an option.
+ Preserves NSAP plans as pseudo-EID.
+ Complexity limited to participating hosts.
- Two independent addressing schemes.
- Still no CLNP service.
o Proposal 4: Tunnel CLNP over IPv6.
+ No modification to IPv6.
+ Preserves CLNP investment.
- CLNP hosts only see each other.
There was no discussion about the viability of scenarios 1 and 4.
However, 3 found little support and 2 is controversial (see later
discussion on address mapping).
Mechanisms:
o M0: The Null mechanism: Tell CLNP users to run IPv6.
o M1: Develop a CLNP to IPv6 transition plan (``Avoid Brutal User
Transition'' ABUT).
+ Stepwise transition like SIP/TUBA.
- Some folks think that this might be expensive.
(Not clear what they mean by ``expensive,'' or what is the
alternative.)
o M2: Squeeze NSAPs into 16 bytes.
- Does not appear to explain all of the transition steps that are
necessary.
o M3: Map IPv6 addresses within the NSAP format.
+ Useful for stepwise transition.
- This also is not complete plan (may be part of M1, for
example.)
o M4: Carry full NSAPs in IPv6 extension headers.
+ Preserve rull NSAP space.
- Complicates routing (how, details uncertain).
- Implementation complexity.
o M5: Carry NSAPs as end-to-end option.
o M6: Encapsulation of CLNP over IPv6: nextheader=CLNP.
(This is easy given current standards and software.)
o M7: Update RFC 1006 (TP0 or TP4 over TCP over IP).
(Seems to be simple.)
o M8: Support TP4 directly over IPv6.
(This is easy given current standards and software.)
o M9: Map NSAPs to IPv6 addresses via DNS.
Ross Callon gave an overview of ABUT (TUBA backwards) which he will
summarise for the mailing list. Essentially it is a dual stack
transition as proposed for TUBA and IPv4 to IPv6.
Jim Bound gave a description of a mechanism for mapping NSAPs into 16
byte IPv6 addresses.
o Split CLNP address into a high part and low part
o Map the high part and recombine with the low part
For details see draft-carpenter-ip6-nsap-map-00.txt.
This draft is alleged to cover all known deployed CLNP addressing
schemes (ICD and DCC formats with unused and reserved bytes deleted).
Proponents of other schemes need to show why this is insufficient.
Ross pointed out that the ABUT transition scheme does not require any
particular relationship between CLNP and IPv6 addresses. Each
organisation can use whatever means it wants (assuming that the
addresses are topologically reasonable). It is permitted and reasonable
to use the Jim/Brian address mapping, but ABUT does not require that all
organisations coordinate their means of mapping NSAPs into IPv6
addresses.
Jack Houldsworth gave an overview of NSAPs. He pointed out the
flexibility of NSAPs (for example, the ability to encode X.121, F.69,
E.163 and E.164, etc). One question came up regarding which of these
formats are actually used? Clearly E.164, DCC, and ICD are being used.
Perhaps the biggest difference between NSAPs and IPv6 addresses is that
NSAPs explicitly allows embedding of many different other address
families, whereas IPv6 addresses are expected to be assigned for IPv6 in
a topological/well packed manner. Jack also proposed a scheme where the
IPv6 address field would be the ``top'' of an NSAP, with the leftover
part in an IPv6 option. For details see
draft-houldsworth-ip6-nsap-use-00.txt.
A transition mechanism for ABUT was proposed by Ross Callon here. If
what comes back from DNS is an IPv6-type NSAP address, then use simple
IPv6. Otherwise, do another DNS lookup to map the ``real'' NSAP into
IPv6, and then encapsulate the full NSAP address. We could first
migrate the CLNP world towards trivially IPv6-mappable addresses.
Alan Lloyd discussed options for sorting out addressing. His goals are:
To provide ``harmonisation'' between ISO NSAPs and IPv6 addresses; to
permit ISO to administer some of the IP address blocks; to provide a
network design approach that enables address convergence to IPv6. He
stated a requirement: to have compatible address forms for NSAPs and
IPv6. IPv6 in NSAPS are easy. For NSAPs in IPv6, propose to assign
first bytes of IPv6 addresses to be compatible with some NSAP AFIs.
These need to use assigned NSAPs which fit into 16 bytes. This thereby
allows ``bi-lingual'' addresses. For details see
draft-lloyd-ip6-iso-itu-reg-00.txt.
The view that IPv6 addresses and NSAP addresses (such as those for ATM)
should be harmonised, i.e. part of the same global address space, was
strongly defended by Alan Lloyd. [However, it seems to be at odds with
the architectural view of IP as ``one protocol to bind them all'' with
an over-riding address space. This architectural issue was not clearly
identified during the BOF, but has since been raised on the mailing
list. Further debate on this is required.]
Multiple people were concerned about the implications of splitting the
NSAP address between two parts of the header -- the first ``n'' bits in
the IPv6 address, and the rest in an extension. Keith Sklower was
concerned about embedding the NSAP length as the high order part of the
address, since this causes an explosion in the number of routing entries
in forwarding tables. Jim Bound and Ross Callon expressed support for
the notion of providing a graceful migration from CLNP to IPv6, but also
expressed strong concern with specific technical aspects of Alan's
proposal, stating that the proposal had to work well and be
implementable, reasonable efficient, and manageable.
Dan Harrington, DEC presented an alternative proposal. The ``top'' of
an NSAP (actually the part useful for routing) is in the IPv6 address,
and the entire NSAP is carried in a header extension. This is similar
to the Houldsworth/Lloyd proposals but perhaps slightly cleaner.
It appears that all of these proposals are compatible with the ABUT
transition scheme, in which either CLNP or IPv6 is used end to end for
any particular datagram.
Work items:
o Description of the ABUT plan (Ross Callon)
o Address mapping needs to be worked on (all, combined proposal
needed)
o Tunneling (simple, but volunteer needed)
o TP4 over IPv6 (new work, volunteer needed)
o RFC 1006+ (fairly simple, Scott Bradner was heard to volunteer)
Action items: proposers will write up their own proposals if not done.
The group expects to meet again in Danvers. The objective would be to
decide whether ABUT and/or a combined address mapping proposal should be
followed up (working group chair and activists needed for that). The
architectural issue about address space harmonisation also needs to be
resolved.
To subscribe to the NOSI mailing list, use
majordomo@sunroof.eng.sun.com, and write subscribe nosi in the text. At
present this is not an archived list.