home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1997 December
/
Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso
/
ietf
/
ipae
/
ipae-minutes-92nov.txt
< prev
next >
Wrap
Text File
|
1993-02-17
|
12KB
|
234 lines
CURRENT_MEETING_REPORT_
Reported by Dave Crocker/TBO
Minutes of the IP Address Encapsulation Working Group (IPAE)
IPAE seeks to facilitate Internet conversion to a replacement for the
current Internet Protocol (IPv4) by attending to transition ease of the
installed base. The primary impetus for replacement of IPv4 is its
limited address space, containing too few bits and having too little
structure for very large-scale global routing tables. IPAE's technical
approach is to encapsulate the new addressing information inside old
IPv4 headers, so that the new information can transit unmodified
networks.
After the Boston (24th) IETF meeting, the IPAE Working Group held a
series of face-to-face meetings in Mountain View, California and usually
with video conference hookups to Cambridge, Massachusetts. Telephone
conferencing bridges also were available. EMail activity during this
time was relatively limited.
During the time of these interim meetings, Steve Deering, who also had
been participating in IPAE meetings, developed a preliminary
specification for a Simplified IP (SIP) which streamlined the classic IP
header, including addresses of 64 bits. Over the course of the interim
meetings, IPAE then repositioned itself to focus exclusively on the
question of transition from IPv4 to the new IP, with detailed
specification of the transition focusing on use of SIP as the final
stage of deployment.
Working documents of the Working Group are maintained in the at host
`parcftp.xerox.com', in directory `ip-encaps'. Prior to the Washington
IETF meeting, the IPAE specification was updated in the internet-drafts
directory of the Internet Repository. Its filename is
`draft-crocker-ip-encaps-01.txt'.
November 19th
The IPAE session divided into a small amount of review about IPAE, some
discussion of a few open technical issues, and then an extended
presentation about implementation experience, by Erik Nordmark of Sun
and Ron Jacoby of SGI. The Sun implementation is a full IPAE/SIP set of
functionality, at the internet layer, and has been tested with SIP-SIP,
SIP/IPAE-IPAE/SIP, and SIP-IP interactions. A copy of Nordmark's
presentation is attached.
Noteworthy comments about his technical work, on a Unix System V streams
base:
o Converting to 64-bit address was somewhat tricky. (Author note:
Comments from an earlier effort with BSD code suggests that the
1
effort was not trivial, but also was not too difficult, though
addresses larger than 96 bits may pose a problem.)
o Adding re-assembly code was easy, since it is identical to IPv4's
reassembly. It took about a half a day's effort.
o Initial throughput testing (on prototype code) showed performance
about the same as for IPv4. It must be stressed that the testing
was by no means thorough, nor was the code tuned.
Open technical issues for IPAE include Domain Name System, network
management and routing enhancements. DNS changes appear to be generic
for any addressing upgrade, as do the general requirements for changes
to MIB variables, and use of a routing protocol. That is, conversion to
larger addresses carries a requirement for a substantial set of changes
to Internet components. IPAE (and SIP) appear to impose no special
concerns for this.
SIP uses addresses which have an IP address in the lower 32-bits. There
was a suggestion that sites add a DNS entry which contains the UPPER
32-bits, so that hosts would have easy access to that information via
the DNS. (Author's note: This presumes a direct relationship between IP
network addresses and DNS domains, which is not required by the DNS
technology.)
In questions from the audience, there was some tension between
facilitating transition, versus ensuring a high-quality end-point.
There also was a question of the Group that would have to absorb the
pain of a transition, with the choice being end-users, versus system
operators. (Author's note: The term ``end-user'' is ambiguous, since
local-net administrators are end-users, relative to larger service
providers. Hence, there is a range of targets for absorbing transition
pain.)
Vint Cerf observed that users aren't interested in the question; they
simply should not be the ones to do the absorbing.
2
^L
===============
| 1. |
Internet | Packet from |
layer: | transport |
Transmit side | |
===============
|
v
---------------
| 2. |
| Lookup SIP |
| destination |
| |
---------------
|
v
---------------
| 3. |
| Finish SIP |
| header (src |
| address) |
| |
---------------
|<------------------- From 21
------------------------?----------------
| | |
Dest is the C-bit(dest) and Other destination
local host. in this site. |
| | |
v v v
=============== --------------- ---------------
| 4. | | 5. | | 6. |
| Deliver to | | Convert SIP | | SIP frag- |
| transport | | to IP | | mentation |
| | | | | (if needed) |
=============== --------------- | |
| ---------------
v |
--------------- --------?--------
| 7. | | |
| IP header | C-bit(next_hop) Other next_hop
| checksum | | |
| | v |
--------------- --------------- |
| | 9. | |
v | Encapsulate | |
--------------- | in IP hdr | |
From 15 ------->| 8. | | | |
| IP frag- | --------------- |
| mentation | | |
| (if needed) | | |
--------------- | |
| | |
---------------------------------
|
v
===============
| 10. |
| Transmit |
| (incl ARP) |
| |
===============
^L
Internet Goto after 3
layer: ^
Receive side |
=============== --------------- ---------------
| 22. | | 20. | | 21. |
| Deliver to |<--------| SIP reas- | | Decrement |
| transport | | sembly. | | SIP hopcount|
| | | | | |
=============== --------------- ---------------
^ ^
This host Other destination
| |
----------------?--------
|
---------------
-------------------------------->| 19. |
| | Lookup SIP |
--------------- =============== | destination |
| 17. | | 18. | | |
| Strip IP | | Deliver to | ---------------
| header | | transport | ^
| | | | |
--------------- =============== |
^ ^ |
Protocol == IPAE Other protocol |
| | |
?---------------- |
| |
| Goto 8 -----------------
| ^ | |
--------------- --------------- --------------- |
| 14. | | 15. | | 16. | |
| IP reas- | | Decr. ttl | | Convert IP | |
| sembly. | | Update cksum| | to SIP. | |
| | | | | | |
--------------- --------------- --------------- |
^ ^ ^ |
This host This site Other site |
| | | |
--------?------------------------ |
| |
--------------- |
| 13. | |
| Lookup IP | |
| destination | |
| | |
--------------- |
^ |
--------------- |
| 12. | |
| Verify IP | |
| hdr checksum| |
| | |
--------------- |
^ |
IPv4 packet SIP packet
----------------?------------------------
^
|
===============
| 11. |
| Receive from|
| link layer |
| |
===============