CURRENT_MEETING_REPORT_
Reported by Bob Hinden/Sun Microsystems
Minutes of the Simple Internet Protocol Plus Working Group (SIPP)
The SIPP Working Group held an implementors' meeting on Sunday, and two
working group sessions during the week. The first session was on
Wednesday and the second session was on Thursday. The first session was
multicast on the Internet.
The minutes from the implementors' meeting were taken and written by Jim
Bound.
Review Agenda
The agenda for the meeting was:
o Review Agenda
o Working Group Status
o Implementors Meeting Report
o SIPP Specification Update
o Discover / Auto Configuration
o IPAE Overview
Working Group Status
Bob Hinden reported that the working group charter was approved. The
SIPP Working Group is now official!
A ``white paper'' on SIPP was written and submitted to the IPng Area
Directors. It has been published as an Internet-Draft and will appear
as a ConneXions article. This was the only IPng white paper which was
submitted on time.
A large number of documents were published as Internet-Drafts. They
include:
R. Atkinson, ``SIPP Authentication Payload,'' Internet-Draft,
draft-ietf-sipp-ap-01.txt, January, 1994.
W. Simpson, ``SIPP Neighbor Discovery,'' Internet-Draft,
draft-ietf-sipp-discovery-04.txt, March 1994.
W. Simpson, ``SIPP Neighbor Discovery -- ICMP Message Format,''
Internet-Draft, draft-ietf-sipp-discovery-formats-00.txt March 1994.
S. Thomson, ``Simple Internet Protocol Plus (SIPP): Automatic Host
Address Assignment,'' Internet-Draft, draft-ietf-sipp-auto-addr-00.txt,
March 1994.
S. Thomson, C. Huitema, ``DNS Extensions to support Simple Internet
Protocol Plus (SIPP),'' Internet-Draft, draft-ietf-sipp-dns-01.txt,
March 1994.
S. Thomson, ``Simple Internet Protocol Plus (SIPP): DHCP Options and
BOOTP Vendor Extensions,'' Internet-Draft,
draft-ietf-sipp-dhcpopt-01.txt, March 1994.
R. Govindan, S. Deering, ``ICMP and IGMP for the Simple Internet
Protocol Plus (SIPP),'' draft-ietf-sipp-icmp-igmp-00.txt,
Internet-Draft, March 1994
S. Hares, ``IDRP for SIP,'' Internet-Draft,
draft-ietf-ipidrp-sip-01.txt, November 1993.
R. Gilligan, et. al., ``IPAE: The SIPP Interoperability and Transition
Mechanism,'' Internet-Draft, draft-ietf-sipp-ipae-transition-01.txt,
March 1994.
P. Francis, ``OSPF for SIPP,'' Internet-Draft,
draft-ietf-sip-ospf-00.txt, February 1994.
G. Malkin, C. Huitema, ``SIP-RIP,'' Internet-Draft,
draft-ietf-sip-rip-00.txt, March 1993.
S. Deering, et al, ``Simple Internet Protocol Plus (SIPP): Routing and
Addressing,'' Internet-Draft, draft-ietf-sip-routing-addr-01.txt,
February, 1994.
R. Atkinson, ``SIPP Security Architecture,'' Internet-Draft,
draft-ietf-sipp-sa-01.txt, March 1994.
R. Atkinson, ``SIPP Encapsulating Security Payload (ESP),''
Internet-Draft, draft-ietf-sipp-esp-01.txt, March 1994.
S. Deering, ``Simple Internet Protocol Plus (SIPP) Specification,''
Internet-Draft, draft-ietf-sipp-spec-00.txt, February 1994.
P. Francis, ``Simple Internet Protocol Plus (SIPP): Unicast Hierarchical
Address Assignment,'' Internet-Draft,
draft-ietf-sip-unicast-addr-00.txt, January 1994.
A SIPP Mosaic page has been created on http://town.hall.org.
The SIPP Mosaic page includes an overview of SIPP, information on the
working group, a summary of current specifications, and information on
SIPP implementations. Authors of SIPP documents should send a short
biography and picture (in GIF format) to Bob Hinden.
Implementors' Meeting
The SIPP implementors' meeting was organized by Jim Bound, in
collaboration with Steve Deering, Paul Francis and Bob Hinden, the SIPP
co-Chairs.
The SIPP Working Group would like to thank Megan Walnut from CNRI for
assisting the group to obtain a meeting room for this meeting.
The meeting was attended by the following main participants: Steve
Deering, Bill Simpson, Ran Atkinson, Dan McDonald, Sue Thomson, Ramesh
Govindan, Bob Gilligan, Steve Alexander, Jim Bound, Alex Conta and Peter
Grehan. Also in and out were: Christian Huitema, Sue Hares, Dino
Farinacci and Allison Mankin.
The meeting focused on the SIPP protocol specifications and
implementations issues. The meeting was lead by Steve Deering.
The first part of the meeting consisted of status reports. Each
participant presented his/her implementation status:
o Bob Gilligan of SunSoft: The SIPP/IPAE prototype can exchange
messages with IP hosts using the IPAE mechanisms.
o Dan McDonald and Ran Atkinson are working on a NRL implementation
which is at a very initial stage. The intention is to place the
NRL implementation in the public domain.
o Sue Thomson and Ramesh Govindan from Bellcore are also working on
an experimental implementation, which may be made available in
public domain.
o Alex Conta, Peter Grehan, and Jim Bound presented the status on the
Digital IPng prototypes - OSF/1 and OpenVMS. Digital's approach is
to begin the prototype with kernel development for the SIPP
protocol engine that will in the future support SIPP
interoperability testing for the specifications.
The second part of the meeting consisted of a protocol specifications
walk through from the prospective of specific implementations.
The review went deep into the specifics of the SIPP protocol design and
SIPP headers layout. All discussion cannot be possibly captured in
these minutes, and will focus on what was altered as a result of this
meeting.
Steve started the SIPP header review by providing more details regarding
the flow ID field, which is supposed to contain a traffic class
subfield, a quality of service (QOS) subfield and a flow ID number,
which is randomly chosen or negotiated. For setting and getting the
values, Alex Conta, Jim Bound, Ran Atkinson and Bob Gilligan discussed
the potential of using a `setsockopt/getsockopt' type of API operation,
similar to IPv4 in setting IP options. We all agreed on the mechanism
to be used. Alex Conta further mentioned that the model should be
extended to management, such that the implementations will no longer
rely on operating system platform specific mechanisms. Eventually we
could document the mechanisms as part of the SIPP documents or as a
separate document.
Further, during the review of the SIPP header, several commented that
the size of the header and the position of the fields are very well
thought out. Having a header which is a multiple of 64 bits optimizes
caching and memory access, most likely on the 32-bit RISC processors,
but it is optimal in particular on the 64-bit machine architectures like
Alpha AXP.
Alex made the comment that the `payload type' field being used
concurrently for both multiplexing SIPP options and SIPP transport
protocols, presents the risk of limiting the future number of SIPP
options, and SIPP transport protocols. Additional comments on the size
of the `hop limit' field were made, which seems too small - maximum 255.
Though these comments have been made before, Alex felt they should be
made again for clarity of a possible future issue.
Steve commented that the decision on the current field sizes was made
knowing the possible negative effects, and so they were left unchanged.
Further, Alex made the comment that the SIPP payload length limit of 64
Kbytes may be too small in the future. This was also a topic discussed
previously at length in the working group, with the current decision
being defended vigorously by Steve Deering, Bill Simpson, and Ran
Atkinson. It was decided to leave this discussion for now.
Before starting the walk through the SIPP routing header, at the request
of the attendees, Steve briefly presented a transparency on how the SIPP
addressing is used in the SIPP advanced routing-hierarchy of provider,
subscriber, subnet and node ID. Steve mentioned that this explanation
was given to him by Paul Francis, the author of the SIPP advanced
routing. The group felt this kind of clarity in the specifications was
important to capture.
During the SIPP routing header review, Alex made the proposal to shift
the `next addr' field to the right 8 bits, such that accessing and
computation on this field will not require additional shift
instructions. The proposal was accepted in unanimity:
Old:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Type | Num Addrs | Next Addr | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. . .
New:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Type | Num Addrs | Reserved - MBZ| Next Addr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. . .
During the SIPP fragment header review, Alex made the proposal to shift
the `more fragment' bit to the very left, and leave the reserved bits
next to the fragment offset. Then Alex proposed that the fragment
offset be the natural offset value rather than the offset shifted by 3
bit positions to the right. The proposal was accepted in unanimity:
Old:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Type | Reserved |M| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . .
New:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Type |M| Reserved | Fragment Offset |0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . .
Additionally, Alex commented that since the offset is now a natural
value, there is no other reason to require the 3 lowest significant bits
to be zero and thus the fragments size be a multiple of 8 bytes, other
than compatibility with IPv4 fragments, which is important for IPv4 to
SIPP transition and coexistence.
Everyone in the room liked the way the header looked after the change,
and the general comment from Steve Deering and Bill Simpson was that the
meeting was very substantive and therefore successful, and that they
would like the working group meeting to be the same.
During the discussions, Dino Farinacci joined the participants, and
requested a move of the flow ID next to the SIPP source address for
speeding up the flow ID-based caching and lookup. The group in general
thought this was a very good idea, but unfortunately the field sizes did
not allow an easy move, and therefore the change was dropped for now and
would need some thought. It was generally accepted that we needed to
keep the source and destination addresses aligned on 32-bit boundaries,
as this is a big win perceived from most participants.
On the authentication header, Peter Grehan mentioned that it is apparent
that the MD5 algorithm is costly from a performance point of view. Ran
Atkinson mentioned that there are other algorithms that could be looked
at, and he will do that. A brief discussion followed about the position
of the header, and how this affects its processing. Peter further tried
to explain to the group his knowledge gained on the host kernel after
building a prototype analysis for the SIPP security specifications, but
it appeared most had not started this kind of kernel work and the group
was not prepared to discuss this in depth.
At this point, after about 2 or 3 hours of work, the group decided to
break for registration and dinner, and return to continue the discussion
afterwards. The registration and reception took about 30 to 45 minutes.
Slowly the people regrouped and continued the discussion.
On the hop-by-hop option header, Alex proposed a change to make the
options in the header 8-byte aligned, since each hop-by-hop is a
multiple of 8 bytes in length. While discussing the proposal, it became
obvious that the text was not clear, which lead to a misunderstanding
regarding the length of the options. Correctly, hop-by-hop options can
be of any length, but the length of the header is a multiple of 8 bytes.
The text will be corrected, and enriched with a suggestion to align
hop-by-hop options to their natural boundaries.
Christian Huitema underlined the importance of alignment for caching.
Then, when discussing the `packet size issues' Alex reiterated that SIPP
fragmentation/reassembly is allowed in end hosts, and that should be
kept that way. Path MTU discovery will eliminate fragmentation in
routers, but sender end hosts can fragment for UDP/IP applications that
have user messages larger than the MTU size. The discussion that
followed focused on payload size, so Alex presented graphs of the
experiments and measurements done in Digital on OSF/1 and OpenVMS UDP/IP
and FDDI on Alpha AXP. The graphs showed that the UDP/IP packet loss is
a continuously decreasing function of user message size with a minimum
at 64 Kbytes. The explanation is that the CPU time spent for
user-to-kernel space crossing is significantly larger than the time
taken for fragment reassembly, and therefore the system time spent per
user message is inversely proportional the size of the message.
Additionally, Alex argued that for using the pipeline effect of the SIPP
fragmentation for UDP/IP, the size of a datagram must be several times
larger than the maximum data link packet size, and already today there
are 3 data links that have or allow 64KByte MTUs (HIPPI, Fiber Channel,
and ATM). For achieving high performance pipeline for TCP, the window
size limit of 64Kbytes had to be broken. Alex added that future data
links may do fragmentation/reassembly at the link level, similarly to
ATM, thus making the MTU size rather optional, and negotiable, with
values larger than 64Kbytes. Applications such as audio/video use large
messages, etc.
Steve Deering and Bill Simpson argued that the per-packet system cost
should be such that even at a payload size equal to MTU, the network
should be efficient. Given that it was close to 9:00 p.m., Alex gave
up, knowing that there are other ways to fix this.
A short discussion, but no less passionate, followed about transport
layer checksum. Alex and Jim argued for preserving in SIPP the IPv4
checksum characteristics. A slight change in the specifications will
reflect the consensus reached.
Around 9:00 p.m., we all left the meeting with a sense of
accomplishment. Everyone was tired, but the general consensus among all
participants was that the meeting was extremely productive, on target,
and very successful.
Participants at the meeting felt this was a very worthwhile event, and
that it had the technical spirit of the work we should be doing at
working group meetings for any work.
SIPP Specification Update
Steve Deering presented a summary of the changes reflected in the
current SIPP specification.
o The `flow label' is now specified as follows:
4 4 24
+-----+--------+------------------+
| Ver | TCLASS | FLOW ID |
+-----+--------+------------------+
A flow is uniquely identified by the source address and flow ID.
The flow ID is chosen randomly by the source. (There was some
discussion about the value of random flow IDs for authentication.)
Flow forwarding state is obtained from a control protocol or from
information elsewhere in packet. All packets in the same flow must
originate with the same destination address, hop-by-hop header
options, and routing header.
`Traffic class' (TCLASS) specifies the priority of a packet
relative to other packets from the same source. Two priority
ranges are defined: flow controlled traffic and non-flow-control
traffic.
o The authentication header in included in the main specification.
It currently specifies MD5. Some concern was expressed that MD5
might be too slow.
o The hop-by-hop options header was added.
o Addressing details, ICMP, and IGMP were moved to separate
documents. There was some discussion that the basic address
formats should be in the base SIPP document.
Steve Deering also pointed out some corrections to the latest
specification.
o Minor layout changes to fragment header and the routing header
o UDP checksum value of zero disallowed from SIPP source
o Corrected language for hop-by-hop options field size
These changes will be reflected in the next version of the
specification.
ICMP and IGMP for SIPP
Ramesh Govindan presented a summary of the current ICMP and IGMP for
SIPP specification.
The ICMP message format: The header preceding the ICMP message must
have a payload type of 1. The pseudo-header checksum is the same as for
TCP (except for IPv4 (C-Bit = 1) omit packet length).
The processing rules for SIPP ICMP are:
a) Silently discard unknown type messages.
b) Include as much as possible of offending packet as will fit in 576
octets.
A comment was made that it might be better if all pertinent
information was included. Concern was raised about the case when
the routing header had 255 entries.
c) De-multiplex based on the original message payload type.
d) Must not send error messages in response to:
- Error messages
- Packets addressed to multicast destination
- Packet sent as link-layer broadcast
- Not-initial fragment
- SIPP special address
Should not send more than n ICMP message per second for each error
source
Deering suggested an extension to allow MTU discovery when using
multicast. There was also a discussion about rate limiting ICMP error
messages.
For ICMP destination unreachable there are five codes defined:
Destination address unknown
Payload type unknown
Port unreachable
Packet too big
Administrative prohibited
There was a discussion about need for `router unreachable' (to replace
network unreachable)
It was noted that the original ICMP codes should be used.
There was a discussion to add `prefix unreachable.' It was decided to
add a `cluster unreachable' type.
A question was raised about the need for a non-authenticated code point?
A question was raised about the need for a flow state lost message?
Perhaps a new ICMP message? Steve Deering said that currently this is
done in the flow state mechanism, and a separate message is not
required. If a router can not use the flow ID, then it should just
forward the packet with best effort.
The discovery message will be used for both solicitation and
advertisement and will have type/length/value (TLV) encoded
``extensions'' similar to the SIPP hop-by-hop option. The group reached
consensus on basic formats. Bill Simpson will put out document on new
formats.
Media address extension contains the link layer address of the interface
on which the message was sent. Erik Nordmark said this is needed for
things like redirect (to avoid separate address resolution messages).
Dino Farinacci asked if these can these be unicast for networks like
X.25? Bill Simpson said that on networks which support multicast no,
but on nets that do not support multicast it would be okay.
Erik Nordmark said we need to define formats for specific media types.
Bill Simpson said to use assigned number, just like ARP. Dino said that
IDRP has a similar feature, and we might want to use that method.
The routing information extensions include:
Address sequence
Prefix length
Preference
There were some concerns raised about the contents of these documents.
Should there be a single ICMP messages document? A separate document
for discovery formats? Something else? The group consensus was to have
a single message format specification with a separate ``explanations''
document.
SIPP Dynamic Host Address Assignment
Susan Thompson presented the work on dynamic host address assignment.
There are four different combinations which the dynamic mechanisms need
to work. These are:
o DHCP (with new options) for hosts without any routers
o SIPP router discovery to allow host to discover subnet prefix from
a router
o SIPP router discovery and IPv4 DHCP
o SIPP router discovery and SIPP DHCP
All of these mechanisms assume the host has an unique identifier.
Three new DHCP options are defined to support IPAE hosts. These are:
SIPP prefix
IPAE IPv4 reachability mask
List of address sequences of SIPP routers
Options are encoded as tag octet, length octet, and value. The options
support address sequences and support a single SIPP prefix.
SIPP router discovery works by a router advertising local use and global
subnet prefixes. It can solicit a router advertisement on startup or
when an interface is enabled. Hosts maintain lists of subnet prefixes,
masks, and timer, local use addresses, and global address sequences.
Their lists are updated on receipt of a router advertisement. Lists are
also updated on expiration of a timer.
On receipt of a router advertisement per interface a host will:
o Add a local use address when it gets a new local prefix
o Add a global address sequence when it gets a new global prefix
o Add new subnet prefixes to list
o Update lifetime of existing subnet prefixes
The choice of subnet prefixes used should be configurable. Hosts will
delete the associated address sequence when a prefix times out.
Address sequences are formed generally by concatenation of a subnet
prefix and an interface ID. Hosts can use localuse prefix to form a
local use address. Interface can be an IEEE 802 MAC layer address.
This is useful for intra-site communication and for communicating with
SIPP DHCP.
The global prefix is used to form a global address sequence. In this
case the identifying address is a globally unique address. These
address sequences are not IPv4 compatible and the address sequence must
be at least length two. The interface ID is the MAC hardware address,
if it fits in an 64bit address. SIPP DHCP can be used to acquire an
interface identifier.
The use of SIPP router discovery and IPv4 DHCP work by learning the SIPP
prefix by listening to router advertisements and using IPv4 DHCP to
acquire an IPv4 address. These are concatenated to form an IPv4
compatible SIPP address. This only supports single subnet prefix per
interface.
SIPP router discovery and SIPP DHCP work by using the router discovery
to learn the global prefix and SIPP DHCP to acquire a SIPP address
sequence. This approach supports multiple prefixes per interface.
The reason for defining SIPP DHCP is that current DHCP is IPv4 specific.
It needs to support multiple bindings per interface. SIPP DHCP is
simpler because the SIPP host can form a local use address itself
because the SIPP host learns its subnet from SIPP router discovery.
A SIPP DHCP server will support both IPv4 and SIPP clients. The two
types are distinguished by the use of different opcodes in the message.
IPv4 compatible addresses are allocated out of a common database with
IPv4 addresses.
SIPP DHCP maps subnet prefix and client identifier to an address
sequence and lease time. The operations supported are:
o Allocate and bind an address sequence to a client in the subnet
o Look up an existing address sequence in a subnet
o Renew the lease time of a specified address sequence
o Delete specified binding and deallocate address sequence
After the lease time expires, the server may delete the binding and
deallocate the address sequence.
DHCP should allow for multiple servers to offer address sequences in the
same subnet. Unfortunately, no mechanism to ensure consistency between
them exists today. Servers cannot administer the same range of
addresses in a subnet and ensure that a single binding exists per host
per subnet. The implications are that a potential tow step allocation
procedure (discover and select) and identify single binding when
necessary are required.
Address allocation with multiple servers works by the client
multicasting a discovery message specifying the subnet. The servers
make offers. The client chooses one offered address sequence. The
client multicasts assign specifying offer and server. Specified servers
send an acknowledgement, and others retract their offer. Other choices
for this are that servers assign address sequence with zero lease.
Servers return an acknowledgement when binding exists.
Address renewal works by a client unicasting a renew message specifying
the binding and server. The client multicasts a renew when the lease
time nears expiration, and retransmits at half of the remaining lease
time. Specified server extends and returns lease time in
acknowledgement.
Addresses are looked up by a client multicasting a query message
specifying the subnet. Servers with a binding return address sequence.
More than one address sequence may be returned. It is useful to avoid a
two step operation on look up and to determine whether binding exists.
The DHCP equivalent is to verify a specified address.
IPAE Overview
Bob Gilligan presented an overview of IPAE.
The objectives of IPAE are to:
o Allow SIPP and IPv4 hosts and routers to interoperate
o Allow the Internet to transition smoothly from IPv4 to SIPP
o Extend the life of the installed base of IPv4 hosts and routers
IPAE's features include:
o SIPP and IPv4 hosts can interoperate until IPv4 addresses run out.
o Hosts do not need to change addresses when upgraded.
o Hosts and routers can upgrade incrementally.
o No upgrade interdependencies between hosts, routers, or DNS.
o SIPP and IPv4 within a domain interoperate after IPv4 addresses run
out.
o Leverages installed base of IPv4 routers.
IPAE mechanisms are composed of a number of mechanisms to make
transition possible. Most visible is SIPP address format that is
designed to be compatible with IPv4 address (contains IPv4 address).
IPv4 are treated as subnet in SIPP routing. This allows SIPP to be run
over an IPv4 cloud. Part of this is a mechanism to tunnel SIPP traffic
in IPv4 (tunneling). Other is to translate IPv4 and SIPP. This permits
SIPP traffic to flow over most of the Internet. IPv4 to SIPP
translation to help with IPv4 routing scaling.
The IPAE address format is:
64-bit compatible SIPP address format:
1 31 32
+---+---------------+---------------+
| C | SIPP Prefix | IPv4 Address |
+---+---------------+---------------+
This allows IPAE addresses to be assigned to SIPP hosts, with the C bit
defining which (C=1 is IPv4, C=0 is SIPP).
The idea behind the IPAE routing model is that we can treat clusters of
IPv4 as a single SIPP subnet. Packets to SIPP destinations within a
cluster are tunneled SIPP in IPv4. Packets to IPv4 destinations within
clusters are translated to IPv4. Packets to on-subnet destinations sent
in raw SIPP or IPv4 form. Tunnel/translate/raw decision is made by
using the C-bit and IPv4 reachability mask.
o IPv4 clusters
Requirement is that IPv4 be routable to all subnets in a cluster,
with at least one IPAE router at the border. Cluster can be
identified by a single SIPP address prefix. IPv4 routing is
allowed between clusters and can run parallel to SIPP routing.
Cluster can range from the entire Internet to one subnet.
o SIPP/IPv4 routing model
IPAE routers must route both SIPP and IPv4 traffic. They
participate in both SIPP and IPv4 routing protocols. IPAE hosts
have neighbor IPv4 and SIPP routers. Neighbor SIPP routers may be
on the same subnet, and off subnet but on the same cluster.
o Host and router configuration
IPv4 reachability mask (cluster mask) defines the IPv4 scope of the
cluster. SIPP address of neighbor SIPP routers (both on subnet and
off subnet within cluster). Configuration mechanisms in system
discovery, BOOTP/DHCP extensions, and configuration files.
SIPP in IPv4 tunneling is used to reach SIPP destination in clouds.
Can always tunnel to a destination in an IPv4 cloud if you have its
SIPP address.
o Translation of SIPP to IPv4
C-bit and reachability mask tell if packet should be translated.
No configuration or mapping table is needed.
o DNS Algorithm
A new DNS record format has been defined. Records may be added for
both IPv4 and SIPP hosts. SIPP records are optional, IPv4 records
must exist. The hostname lookup algorithm is:
1. Lookup SIPP records first, IPv4 records second.
2. Traffic is SIPP if SIPP record is found.
3. Traffic is IPv4 if IPv4 record is found.
Jim Bound suggested getting rid of the term IPAE Address; he said it
should just be a SIPP address and thinks naming is important to make
these issues clear.
There was discussion about what can and cannot talk to a IPv4 address.
How will host know if its SIPP address is an IPv4 address capable
address, or is non-IPv4 capable. Need to know if it can be translated
or not.
This lead to a long discussion about the complexity of IPAE. It would
appear that many people are having difficulty understanding why the
mechanisms are there and how they work. The conclusion was that IPAE
will need to be simplified and a new document written which makes the
issues clear.
Attendees
Kannan Alagappan kannan@sejour.lkg.dec.com
Steve Alexander stevea@lachman.com
Michael Anello mike@xlnt.com
David Arneson arneson@ctron.com
Randall Atkinson atkinson@itd.nrl.navy.mil
Jim Binkley jrb@cs.pdx.edu
Ute Bormann ute@informatik.uni-bremen.de
Michael Bradley bradley@mdd.comm.mot.com
Michael Bringmann michael@rd.qms.com
Jerry Burchfield burchfiel@bbn.com
Ross Callon rcallon@wellfleet.com
Frank Cannata cannata@cabletron.com
John Carlson johnc@cac.washington.edu
Paul Chang pchangmac@asante.com
Ping Chen ping@apple.com
Robert Christ rchrist@fhcrc.org
Paul Ciarfella ciarfella@took.lkg.dec.com
Bobby Clay clay@pscni.nasa.gov
Alex Conta conta@lassie.lkg.dec.com
Matt Crawford crawdad@fncent.fnal.gov
Jonathon Crowhurst crowhurs@admin.ogi.edu
Stephen Deering deering@parc.xerox.com
Chuck deSostoa chuckd@cup.hp.com
Peter DiCamillo Peter_DiCamillo@brown.edu
Donald Eastlake dee@lkg.dec.com
Kjeld Borch Egevang kbe@craycom.dk
William Fink bill@wizard.gsfc.nasa.gov
H. Tom Fitzpatrick fitz@ddn.af.mil
Paul Francis francis@cactus.slab.ntt.jp
Jerome Freedman jfjr@mbunix.mitre.org
William Gilliam wag@cup.hp.com
Robert Gilligan Bob.Gilligan@Eng.Sun.Com
Ramesh Govindan rxg@thumper.bellcore.com
Peter Grehan grehan@flotsm.ozy.dec.com
Chris Gunner gunner@dsmail.lkg.dec.com
William Haggerty haggerty@ctron.com
Marc Hasson marc@mentat.com
Robert Hinden hinden@eng.sun.com
Richard Hovey hovey@silkie.enet.dec.com
Christian Huitema Christian.Huitema@sophia.inria.fr
Yoshinobu Inoue shin@hodaka.mfd.cs.fujitsu.co.jp
Ronald Jacoby rj@sgi.com
Robert Karsten robert@lachman.com
Alan Katz katz@adonis.com
Manu Kaycee kaycee_m@timeplex.com
John Larson jlarson@parc.xerox.com
Paul Leach paulle@microsoft.com
Fong-Ching Liaw fong@eng.sun.com
Joshua Littlefield josh@cayman.com
Charles Lynn clynn@bbn.com
J. Scott Marcus smarcus@bbn.com
David Marlow dmarlow@relay.nswc.navy.mil
Michael Massa mikemas@microsoft.com
Daniel McDonald danmcd@itd.nrl.navy.mil
Glenn McGregor glenn@lloyd.com
Michael Michnikov mbmg@mitre.org
Stephen Nahm sxn@sun.com
Rina Nathaniel rina@rnd-gate.rad.co.il
Erik Nordmark nordmark@eng.sun.com
William Nowicki nowicki@sgi.com
David O'Leary doleary@cisco.com
Krishnan Parameshwaran krishnap@microsoft.com
Brad Parker brad@fcr.com
Andrew Pearson pearson@snmp.com
Alan Perelman a_perelman@emulex.com
George Phillips phillips@cs.ubc.ca
Ram Ramanathan ramanath@bbn.com
Ron Roberts rgr@stanford.edu
William Robertson rob@agate.berkeley.edu
Chris Seabrook cds@ossi.com
Katsuhiro Sebayashi sebayasi@tnlab.ntt.jp
William Simpson Bill.Simpson@um.cc.umich.edu
Frank Solensky solensky@ftp.com
Fumio Teraoka tera@csl.sony.co.jp
Richard Thomas rjthomas@bnr.ca
Susan Thomson set@bellcore.com
Randy Turner rturner@qms.com
Tony Valle valle@huntsville.sparta.com
John Veizades veizades@wco.ftp.com
Gary Veum veum@boa.gsfc.nasa.gov
Mark Vickers mvickers@fhcrc.org
Justin Walker justin@apple.com
Jost Weinmiller jost@prz.tu-berlin.de
Geoff White geoff@nexsys.net
Walter Wimer ww0n+@andrew.cmu.edu
Jane Wojcik jwojcik@bbn.com
Shian-Tung Wong shian@dcsd.sj.nec.com