(sipp) SIPP Working Group Minutes

[Bob Hinden <[e-mail]>]

Attached are the SIPP working group minutes from the Toronto IETF
meeting.  Corrections to me.

Bob



SIPP Working Group
30th IETF, Toronto
----------------------------------------
 
Steve Deering - Xerox PARC      Co-Chair
Bob Hinden - Sun Microsystems   Co-Chair
Paul Francis - NTT              Co-Chair
 
The SIPP working group held two working group sessions and one
implementors meetings.  The first session was on Wednesday and the second
session was on Thursday.  The implementors meeting was held on Friday.
 
The minutes for the working group sessions were taken by Ross Callon.
The implementors meeting notes were taken by Bob Hinden.

==================================================================
 

SIPP Working Group, Wednesday
- -----------------------------

Bob Hinden started by going over the agenda, and introducing the 
recommendation of the IPng area directors from Monday morning. 

Agenda
 - Review agenda
 - Discuss IPng recommendation and future direction
 - SIPP specification (Steve Deering)
 - Addressing Architecture (Bob Hinden)
 - Simple transition moved to transition working group.
 - Christian's miscellaneous topics
 - Address Allocation Architecture (Yakov Rekhter)
 - Source Routing (Tony Li -- joint with SDRP working group)
 - Real Time (Chuck Davin)
 - To Do list (assign people to jobs)

IPng AD Recommendations
 - SIPP header format (with extension headers)
 - 16 byte fixed length addresses
 - SIPP security work
 - Simplified transition (SST)
 - ...

Open Areas
 - source routing
 - max payload size and minimum MTU   
 - auto-configuration and re-addressing
 - authentication and encryption options
 - pseudo-header checksum rules
 - address assignment plan
 - tunneling
 - mobility
 - header compression

The working group agreed that SIPP should disband after this IETF, and we
should put our effort into the new (and noticeably similar in many
regards) IPng effort.

The basic IPng header becomes 40 bytes, with 32 byes of this being source
and destination addresses. Nothing else has changed except that "payload
type" has been renamed to be "next header".

Minor header tweaks have been made to the Fragmentation Header and to the
Routing Header.

A new end to end options header has been defined. This is a "bag" of
options, and allows conveyance of "ignorable" options on end to end basis
(strictly host to host). This header is for options which, if not
understood, should be ignored by the destination host.

Note that current SIPP (and future IPng) header format does not preclude
using EIDs, although they are not explicitly specified.

Dave Clark is to provide text here regarding EIDs and flow ID, which may
be set by the host as well as by routers and can be used to speed
processing..

Addresses once again identify interfaces and not nodes. This is related
to multicast (specifically, an obscure problem which was found in the
IS-IS working group in Seattle).  There is a request to add the
justification / description of the problem to the IPng draft.

Due to the simplification of the transition plan, the C-bit is gone
(replaced with prefixes). This effects the detailed text of checksumming
rules. There is also a slight change to UDP checksumming rules.

An appendix has been added on how to design options.

Issues:

 - Jumbograms: How large should the upper bound be? How should this be
   encoded (perhaps with a not-quite-straight-linear encoding, such as if
   first bit is 1, implying a greater than 32K packet, then the length is
   in 8-byte multiples rather than one byte multiples).

 - Minimum MTU: What are the tradeoffs here? 

 - Fancier source routing. Source routing reversibility versus authenticate-
   ability. 

 - Authentication header format and semantics: This is in flux. The IPv4 
   security group is paying attention to the IPng requirements which may result
   in some (probably small) changes to this field. 

 - Changes to pseudo-header checksumming rules (e.g., due to SST and/or due
   to authentication header). When we are authenticated strongly, then
   why should we make use of a pseudo-header checksum at all? (the
   protection against changes to the packet provided by a good signature
   algorithm is much stronger than the protection provided by the IP/TCP
   checksum).

 - One more change, the name "SIPP" is being changed to "IPng". Or,
   perhaps we could call it IPv6 (pronounced IP Six). The group voted
   overwhelmingly for IP6.

The working group then entertained questions and open discussion of issues:

 - What routing are we planning on having? Same as IPv4 (except not BGP,
   this will be replaced by IDRP).

 - Revisit minimum MTU issue: The main reason for this is to allow
   bigger UDP packets (e.g., for SNMP and other applications running over
   UDP over IPng).  Given that MTU discovery is required by IPng, this
   implies that the IPng conversation between two hosts will use larger
   packets if and only if the subnets can carry it (?Does this help UDP
   applications much?). IPng over localtalk is a reason for smaller MTUs.
   Also there are some systems in orbit which are working with 576 byte
   MTUs (service calls are extremely expensive on satellites -- something
   about space shuttles and rocket fuel prices here).

 - JumboGrams: Larger MTUs are useful in special very high performance
   local networks. Ultranet optimizes at approximately 200Kbyte packets.
   Once you hit a router, this tradeoff changes to prefer smaller packets
   (at least much smaller than 200Kbytes). As links get faster and more
   reliable, the optimal size for packets increases. Datacommunications
   are changing. Various forms of video and supercomputers result in very
   large files being sent. We need larger MTUs for larger files.

If you increase the field size then you have made a syntactical change to
the packet, but this doesn't ensure that you will be able to send those
large packets over the links. Routers have to control the latency, which
implies that MTU size will have to take into account the speed of the
link and the desired maximum delay (per hop). This means that in some
cases supercomputers may discover a small MTU size due to latency or
other considerations for other traffic through intermediate hops.

The maximum MTU size is tied into the design of the hosts. Supercomputers
are currently designed such that a very large MTU is optimal.

The problem with MTU is latency, not processing. So, lets look at the
rate of increase of the speed of the pipes. Eventually we will therefore
need large packets.

One suggestion is that a length of zero is an escape to a hop-by-hop
option, which contains a larger (32-byte) real length field. This was
accepted.

 - APIs should be a priority. 

 - We need to get a big picture of the work ahead of us, so that we can
   get our hands around it. Vendors have to come up with their own
   prototype and product strategy.

   Note: At this point the IPng area directors demonstrated the need for
   portable computing devices to have good user interfaces.

 - Choice of Protocol type / Ethertype issue. From the NHRP (ROLC)
   working group, there is a need to identify protocol / address family
   in a number of protocols (for example, to identify address type in
   IDRP).  Also, a different Ethertype / DataLink type would create a
   clearer dual stack. The problem is that this would have an effect on
   all media.  Changing all of the link layer types would be a lot of
   work (with relatively little to show for it). This has a widespread
   effect on implementations.

   Another issue related to link layer protocol types involves the
   possibility of IP code breaking when it sees a packet which the link
   claims is an IP packet but which the IP code doesn't recognize. This
   could result in a large number of apparent checksum errors (but
   shouldn't happen unless there is some sort of configuration error). We
   should to go out and check whether routers are checking the IP version
   (what are existing routers going to do when they get an IPng packet?).

 - For SST prefix(es), why not use a prefix which sums to zero under
   the IPv4 checksum? Thus, instead of using 0:0:0:0:0:0 and 0:0:0:0:0:1
   for prefixes in SST, why not use 0:0:0:0:0:0 and 0:0:0:0:0:FFFF?

Source Route Discussion, joint with SDRP (Peter Ford): At this point the
SDRP working group joined us for a discussion of source routing.

Hop by hop forwarding is not sufficient as the **ONLY** forwarding method
for IPng (reasons for alternative include mobility, virtual private nets
on top of provider infrastructure, provider selection, TOS, Multicast,
transit policies, etc). We need to go beyond the current hop by hop
forwarding paradigm. Source routing is part of what is needed for use in
some cases.

Need to be able to specify a routing domain in a source route (or an
aggregation of some sort, not just a single real router). Need to be able
to deal with route failures (what if specified next hop cannot be
satisfied?).

Strict versus loose indication has to be on a per-hop basis.

The source route option is variable length up to 32 intermediate hops,
with a pointer to indicate the current hop, a bit mask to indicate strict
versus loose for each hop, plus a length field, etc. The source route
address list contains all addresses (including the final destination, but
not the source), so you don't do a swap, you just do a write. This also
helps if the source route header needs to be authenticated (since only
the pointer field changes -- and you could simply not authenticate this
one field).

There is a concern about the length of addresses in the source routing
field (the total amount of information which needs to be carried in the
field causes the limit of 32 hops). Concern about amount of "heavy duty
header munging" which needs to do this in high speed routers.

There needs to be an option to allow a source routed route setup, with
subsequent packets forwarded based on flow ID, with most packets not
carrying the source route.

There is a question regarding whether the source route can be added by
routers (as an alternative to adding it by the source host). Clearly this
is possible if the router encapsulates in a new IPng header, and uses a
source routing header in the encapsulating IPng packet header. There is
some interest in doing this without adding an additional IPng header in
order to save bits, particularly if multiple routers at different levels
of the hierarchy have to add source routes (at different levels).

The co-chairs of the SDRP working group are willing to accept the
ownership of the source routing header. This implies that source routing
will be in a separate document. However, this is so important that it is
important that using a different document does NOT imply a lowering of
the importance of the header.

==================================================================

SIPP Working Group, Thursday
- ----------------------------

The IPng Mailing List has been set up as: [e-mail]
To join, send an email message to: [e-mail]
with "subscribe ipng" in the text of the message

We discussed the addressing architecture internet-draft:
 
Changes from last version:
	- remove c-bit
	- extended addresses removed
	- source route reversal rules moved to main SIPP specification
	- address types defined
	- removed text for binding addresses to specific interfaces

Basic format for writing addresses in text: 
	- twobytesinhex:twobytesinhex:etc:etc:etc:etc:etc:etc
	- can compress leading zeros
	- can compress middle zeroes (only one set thereof)
	- IPv4 format replaces the last 32 bits (two * two bytes) with IPv4
          dotted decimal notation

Currently assigned address types:
	00		reserved
	01		provider based unicast
	10		geographic
	110		reserved
	1110 00		NSAPs
	1110 01		reserved
	1110 10		reserved
	1110 11		IPX allocation
	1111 00		reserved
	1111 10		reserved
	1111 110	reserved	
	1111 1110	local use
	1111 1111	multicast

It has been suggested to move some of the allocated values together, in
order to allow the reserved blocks to be contiguous in more cases. For
example, the NSAP allocation and the IPX allocation might be moved to be
contiguous.

Cluster addresses are a specific form of one of the other types of
addresses.  For example, some cluster addresses might correspond to
provider based unicast.  Currently, there is no allocation for anycast.
However, if (when) someone figures out how to do anycast, there is plenty
of space left to allow this to be added.

Brian Carpenter has a proposal regarding how to map NSAPs into this
space.  This is still evolving. There is still some uncertainty regarding
how this will actually be used. Until we know what the use is, it is hard
to determine precisely whether the mapping is complete. One important use
which has been identified is to allow existing address allocation plans
to be used for IPng.

A complete mapping is not possible into less than 20 bytes. The important
thing is the logical mapping (to make sure that the necessary information
is mapped), not the exact syntax.

Space is reserved for IPX, but the details have not been worked out yet.

It would be highly desirable to have a convergence of multiple network
layer protocols to IPng. For example, to run OSI applications over IPng.
This might be done via some update to RFC 1006, or in a more
straightforward and efficient way by running OSI application over TP4
over IPng. Some work should be done on this (but this is outside of the
scope of an IPng addressing discussion).

The working group discussed the reverse mapping from address to names via
DNS. Does this have to be based on 16-bit boundaries, 8-bit boundaries,
nibble boundaries, or otherwise? While the written text format has the
":" delimiters on 16-bit boundaries, the hexadecimal digits are obviously
specified on nibble boundaries. Christian Huitema has the action item to
write up a proposed resolution to this issue.

Bob Hinden gave two examples of how addresses might be assigned (on LANs
and on point to point links). It is important to remember that these are
only EXAMPLES, and other formats ARE ALLOWED.

Bob illustrated how unicast provider-based addresses may be
autoconfigured.  This uses a 48-bit "magic cookie" which is assigned to
the host (while it is possible that this may be bit-for-bit identical
with MAC addresses for administrative ease, it is essential that this
must not be required to be a MAC nor a subnet address). The 48-bit magic
cookie is appended to a "m" bit long subnet ID plus an "n" bit long
subscriber prefix (such that 48+m+n comes out to 8*16 bits). The subnet
ID may itself be sub-structured, as may the subscriber ID.

For PPP links with only two ends, the subscriber prefix plus subnet ID
may be longer, possibly leaving only 2 bits for the node ID on a point to
point link (2 bits rather than one so that a value can be assigned to the
wire itself).

Other types of links, such as multi-drop links, may have different
lengths for the node ID field.

Steve provided another example. THIS IS AN EXAMPLE, DO NOT ASSUME THAT
THIS IS THE ONLY WAY TO DO THINGS. In assigning fields, it is useful to
leave unassigned bits in the right places to allow future growth. It is
pointed out that drawing pictures tends to make people jump to
unwarranted interpretations of the picture.

Autoconfiguration / autoaddressing for low end (possibly stub) routers
was pointed out as an important thing. Proposals on how to do this are
welcome.

Private "subscriber" networks with on the order of 1,000,000 nodes must
be allowed (a gentleman from a high-tech-oriented large fortune 100
company pointed this out, quite correctly).

The discussion today is of a provider based scheme. This implies that
when you change your provider, you also change your addresses. However,
it is important that this does not require a change to the local address
allocation scheme used for assigning the "middle" and low order part of
the address within a site. Also, end systems will autoconfigure the
change to the (high order part of) address.  Autoconfiguration of stub
routers and/or small subnets is also important.  however, some part of
the worldwide Internet will need to be configured (we can't autoconfigure
everything).

Christian Huitema proposed that, rather than fitting IPv4 into IPng
addresses at the low order 32 bits, why not do it in the middle of the
address? This allows IPv4 address to be a seed for the IPng addressing
scheme. One possible reason for NOT doing this is that this could lead to
un-careful address allocation.  Current IPv4 addresses are known to be
poorly allocated. There seemed to be a general agreement that this was
sufficient reason to *not* encourage IPng address assignments to be based
on existing IPv4 address assignments.

The proposal is that the minimum allocation to any subscriber is 64 bits.
However, very large subscribers (example of Boeing was mentioned) may get
larger allocations (ie, a shorter prefix means "this is Boeing", Boeing
then gets more than 64 bits to play with). There needs to be some
standard for how long a prefix large subscribers get, so that if they
change providers (or have multiple providers at once) they get the same
length prefix from each. GM was pointed out as another clear example of a
big network what might want more than a 64 bit assignment. It was
suggested that the big guys are very much like providers (perhaps the
real issue comes in middle sized guys, and distinguishing these from the
big guys).

One comment suggested that it is desirable to *not* change addresses
when you change providers. Somehow it was suggested that variable length
addresses may help here, although it was not clear how.

Local use addresses are provided for in this address hierarchy (prefix of
11111110). It is recommended that sites using local addresses start
assigning the address bits from the right, with fill of zeroes from the
left. This allows them to change the high order part of the address when
they later hook up to the Internet. On the other hand, there may be some
systems where we know for sure that they will stay local (example of an
aircraft carrier was given by someone who actually does have a lot of
aircraft carriers -- not purchased with personal funds). These could use
any address from the local space -- there is no particular reason to
assign from the right in the case that we know that the system will
always be only local.

This group is not commenting on the desirability of local addresses.
Rather we are providing the possibility of local addresses for those
folks who think that they will be useful.

A low order suffix of all zeroes is used for cluster addresses.

A local loop back address is defined. This is the local address with the
low order one bit set to one, and the rest set to zero (address
FE00:0:0:0:0:0:0:1). The cluster label for this would appear to be
FE00:0:0:0:0:0:0:0, although some of us were unclear what a cluster
loopback address would mean.

An unspecified address of 0:0:0:0:0:0:0:0: is defined. This is used where
you don't know what an address is. For example, this may be used as a
source address for a system which is sending a packet but doesn't yet
know its own address.

There was a question regarding why the loopback address is from a
different block than the unspecified address. This means that two blocks
have been cut into.

Multicast address (starts with 11111111) has flags and scope. Details
are defined in the spec.

Question: Will we have multi-subnet broadcast addresses? Answer, there is
no broadcast here, only multicast (you should never send to everyone,
rather you should send to the right "lots of folks" multicast address).
In some cases you will need to map IPng multicast onto LAN subnet
broadcast, since some systems receive LAN broadcast more efficiently than
LAN multicast. Some work on multicast addresses is still needed.

Yakov Rekhter gave a presentation on: Architecture for SIPP-16 Address
Allocation (ie, the relationship between addressing and routing).

This document provides guidelines. This is pretty much based on CIDR (ie,
based on NSAP guidelines, based on much earlier work on hierarchical
routing -- this is not a new idea but it works). This is based on what is
currently deployed, which therefore does not require any drastic change
from what we are doing.

The set of administrative requirements for obtaining and allocations IPng
addresses are not discussed. This is not a specific plan for address
assignment, nor does it deal with embedding address space from other
protocols, nor multicast, ... The technical aspects of address allocation
and the implications on routing are discussed in this document.

The benefits of encoding *some* topological information in addresses is
discussed. The need for additional levels of hierarchy, etc..

Hierarchical routing: Scaling requires that we achieve some level of
information abstraction. Within a single-homed leaf domain: This implies
that we give the domain a contiguous block of addresses abstracted into a
single address prefix.  This is preferably from a prefix assigned by the
direct provider.

Providers should have relatively large contiguous block, and give
sub-blocks to customers. If you want to separate "R&E" from "commercial",
you can have the provider have two relatively large sub-blocks.

Question: When we change providers, do we cut a hole in the
CIDR-allocations, or to we require re-addressing. It is desirable to
make it as easy as possible to renumber, thereby allowing CIDR-holes to
be corrected as much as possible.  This does not require that we *always*
renumber however.

It was pointed out that embedding policy (e.g., R&E versus commercial) in
policy is a bad thing. This could explode, or become uselessly
inadequate. Yakov, Steve, some other speakers, and the minute taker were
in agreement on this.  There is a problem that while it may make sense to
some folks (US Government) to split folks into two particular categories,
it may make sense to other folks (other governments or some large
commercial companies) to split folks into different sets of categories.
AUPs (appropriate use policies) will better be addressed by proper policy
based routing capabilities, such as may be provided by SDRP.

Multi-homed domains are harder to handle. There is no one correct
solution.  The document points out four possible solutions, any of which
may be correct in any one particular situation. Thus, it is important to
understand the various solutions in order to determine which should be
used in any one case.

Continental aggregation deals with large blobs of the topology.  This is
anticipated as useful to help contain entropy (if changing providers
results in entropy within one continent, this entropy can be contained).
This could also be useful for multi-homed subscribers which are
multi-homed within a single continent.

Summary: The ability of the Internet to grow depends upon the ability of
routing to scale. This requires the use of routing data abstraction,
based on using addresses which reflect the topology. We recommend
provider-based addresses.

We could start experimenting with geographic addresses, for example for
multi- homed sites which happen to be topologically "close" to one of the
FIX's (there are some examples of this).

Maximum aggregation is not actually needed. For example, there does not
need to be *only* six address prefixes at the top level (one per
continent, probably minus Antarctica). It is sufficient to have a few
hundred or a few thousand at the top. On the other hand, if you shoot for
maximum aggregation, and assign addresses to that maximum aggregation is
possible, this doesn't mean that you have to use it. The important thing
is that when you allocate the addresses you need to shoot for
aggregation.

It must be possible to receive address allocation without connecting to a
public Internet.

Embedding IP addresses in IPng addresses, and NSAP addresses in IPng
addresses, and IPX addresses in IPng addresses, may lead to an unroutable
(or at least hard to route) network. Thus we have to get away from old
bad address assignments to a new more topological more scalable /
routeable address assignment. It may be that some bad addresses may give
you the right to run IPng locally, but *not* give you the right to have
people be capable of routing data to you.

Education is essential. This will be an ongoing process.

Last Topic: Generation of a TODO list:
	- source routing
	- max payload 
	- minimum MTU
	- autoconfiguration and readdressing
	- authenticatioin and encryption
	- pseudo-header checksums
	- address assignment

We need to assign names to documents. 

	- address assignment: take current CIDR assignments and IPng-ize 
	                                (Yakov)
	- address CIDR-stuff		(Yakov)
	- base IPng spec 		(Steve Deering)
	- address architecture	 	(Bob Hinden)
	- DNS 				(Christian H)
	- ICMP/IGMP			(Deering and Conta)
	- MIB				(Kayce)
	- neighbor discovery, Address Resolution    (Bill Simpson, Conta)
	- NSAP mapping			(Brian Carpenter, Jim Bound)
	- APIs				(Bob Gilligan and Jim Bound)
	- security			(Ran Atkinson)
	- compression			(Bill Simpson)
	- FTP	(Foobar)		(Piscitello)
	- SNMP (not MIB)			
	- OSPF
	- IDRP				(IDRP Working Group)
	- IS-IS
	- RIP

Overall consistency is the responsibility of the IPng working group
chairs, and Dave Clark as official IPng Reviewer.


==================================================================


SIPP Implementors Meeting, Friday
- ---------------------------------

Attendees and Interests

Steve Deering / Xerox Parc 
Bob Hinden / Sun: testing, IPngBone
Erik Nordmark / Sun  : Talk about API Issues
Frank Solensky / FTP software
Bill Simpson: Header compression and security
Dan McDonald / NRL : APIs
Mark Hansen / Mentat: want to start prototyping
Dimitry Haskin / Wellfleet
Walt Hauser / Dept. Veterans Affairs: user concerns about universal dial tone.
Frank H / Synoptics
Jim Bound / Digital: everything, have done SIPP8 and SST: header
    	    	     building/filling 
Alex Conta/ Digital: implementing SIPP, addressing (local vs global),
    	    	multicast, 
Peter Gerban / Digital: source routing and API's
Ran Atkinson / NRL: Security aspects, routing header
Justin Walker/ Apple Unix group: similar issues
Ross Callon / Wellfleet: listen
Anthony Martin/ Defense research department : security
Bob Gilligan / Sun
Tony Li / Cisco
Christian Huitema / INRIA


Introduction
- ------------

Steve Deering: Gave introduction on purpose of meeting.  Feedback from
implementors to protocol designers.  Do a walk through of specs or deal
with specific items.  JB: Do important items first.  EN: Also talk about
API issues?  Yes


Security / Ran Atkinson
- -----------------------

Ran Atkinson presented the current work on the security headers.

IPv6 Authentication Header

     +---------------------------------------------------+
     | Next    | Length  |         Reserved              |
     | Payload |         |                               |
     +---------+---------+-------------------------------+
     | Security Association ID (SAID)                    |
     +---------------------------------------------------+
     |                                                   |
     |    Authentication Data (variable length)          |
     |                                                   |
     +---------------------------------------------------+

Several specifications errors were found in the original versions by
Kastenholz, Bellovin, etc.  SAID is receiver oriented (uses destination
address and SAID) SAID are uni-directional.

For now MD5 is mandatory algorithm, but seeking faster algorithm

Key management is disjoint for main protocols.  Want not have to change
security protocol if key management changes.

JW: There will be a API impact.

Issue of performance of algorithm: Existing experience on Alpha got about
20Mbits/sec using MD5.  Could look for another algorithm.  MD4 might be
ok (20% faster?).  What else could be used?

Discussion over how to authenticate source routes.  Suggested having
source do the calculation based on what the source route will look at the
destination.

Can not allow source routes to be inserted in the middle of the path.
Requires mobility to be done with encapsulation.

Proposed IPv4 / IPv6 Encryption Protocol (IPSP)

     +---------------------------------------------------+
     | Security Association ID (SAID)                    |
     +---------------------------------------------------+
     | Algorithm dependent Initial Data (variable length |
     +---------------------------------------------------+
     | Next    | Length  |         Reserved              |
     | Payload |         |                               |
     +---------+---------+                               |
     |                                                   |
     |  Encrypted payload (TCP/UDP/IPv[46]               |
     |                                                   |
     |                                                   |
     +---------------------------------------------------+
     |    Algorithm dependent trailer Data (var length)  |
     |                                                   |
     +---------------------------------------------------+

IPv4 IPSIP proposal does not have next header or length in locations
shown, but hallway discussions w/ IPv6 implements all wanted above.

Sender should use IPv6 PAD to have TCP/UDP/etc data begin on a 64bit
bounty within the protected region (might mean spec revision)

Likely Internet encryption algorithm is DES-CBC other algorithms are
optional.

Suggestion to make length 16bytes

     +---------------------------------------------------+
     | Next    | RSVD    |         Length                |
     | Payload |         |                               |
     +---------+---------+-------------------------------+

There was a discussion of the issues of padding.  General agreement on
64bit alignment.

Make algorithm dependent initial data (variable length)

Discussion about should this be the same for both IPv4 and IPv6.  

Deering suggested that Encrypted payload always start on a 64bit aligned
boundary.  [This solves IPv4/6 compatibly problem?]

Trailer is padding for block size of algorithm in use.

There was a Mention that these options will break NAT boxes.


API Issues / Dan McDonnald
- --------------------------

The issue of the socket interface API was discussed.  Dan McDonnald of
NRL made a strawman proposal that the sockaddr data structure for IPv6
addresses be named "sockaddr_ipv6" and be layed out as follows:


      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  sv6_len      |  sv6_family   |    sv6_port                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Reserved                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                                                               +
      |                                                               |
      +                sv6_addr                                       +
      |                                                               |
      +                                                               +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


There was an issue about the length field (sv6_len).  In the 4.4 BSD (and
Reno) socket interface, the generic sockaddr data structure places a
"length" field in the first byte and a "address family" field in the
second byte.  This is a change from 4.3 BSD, which has a 16 bit long
"address family" field which covers the first two bytes of the sockaddr
data structure.  Many existing systems are based on 4.3 BSD, while some
newer systems are based on 4.4 BSD.

There was some discussion about this, and general agreement that it would
be good if we could define a single IPv6 address data structure that
would be used on both 4.3 and 4.4 based systems.  A single definition of
the data structure would promote application portability among those
systems.

An alternative IPv6 address structure was suggested:


      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      sv6_family               |    sv6_port                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Reserved                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                                                               +
      |                                                               |
      +                sv6_addr                                       +
      |                                                               |
      +                                                               +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

This data structure could be compatible with both the 4.3 and 4.4 based
socket interface if applications are careful to store the sv6_family
value in "network byte order".  When this is done, the first byte of the
data structure will have the value zero on machines with big-endian byte
order as well as those with little-endian byte order.  In order for this
to work, applications must use the following construct to assign the
"sv6_family" field:

	sv6_family = htons(AF_IPv6);

Bob Gilligan will write this proposal up in the next draft of the socket
API spec.

There was some discussion of field alignment in the IPv6 address data
structure.  There was general agreement that 64-bit alignment of the
address field was sufficient; It does not need to be 128-bit aligned.

There was some discussion of the naming of the fields in the IPv6 address
structure.  There was general agreement on the form "sin6_*", however,
this issue is not particularly substantive, so the editor of th API spec
may decide on something different.

There was some discussion about how applications "reverse" source routes.
For TCP-based applications, the reversal can be done in the TCP code.
This has the advantage that it can be transparent to the application
program.  But for UDP-based applications, the application must perform
the reversal.  This raises the issue of how the application retrieves
source routes that are received with UDP packets, and how the application
tells the transport layer to use a source route with packets that are
being sent.  In the current draft of the API spec, the main sending and
receiving functions (sendto and recvfrom) always carry the full source
route.  However, many people thought that this was too complicated,
considering that the common case would be not to have source routes.

There was some discussion of an alternative interface for dealing with
source routes.  In this approach, an application would use a new
getsockopt() option to get the source route that is associated with a
received packet, and then use a new setsockopt() option to set the source
route to be used in transmitted packets.  The commonly used sendto() and
recvfrom() calls would carry a simple single-element IPv6 address.  There
was general consensus that this approach should be worked into the socket
API spec.  Bob Gilligan will include this approach in the next revision
of the socket API spec.


Misc Issues
- -----------

Nordmark asked if you should always add a fragmentation header for UDP
messages.  Deering suggested using MTU discovery.

Suggestion for separate IP6 MTU discovery document (later merge w/ main
IP6 spec).  Alex C. volunteered.


Local vs. Global Addresses  / Alex C.
- -------------------------------------

Goal is to have fast path for transport control block lookups.  Fast path
for address lookups.

90% of traffic will be local.  Want to optimize.  

Suggestion that prefix for local host on this wire be very long as to not
waste address space.  Proposed a method to only use enough info in
address for local identification.

Much discussion.  Some issue for pseudo checksum calculation.

Suggestion for rules for handling of local use addresses.  Only use local
use address if don't have any other addresses.

No consensus on this approach.  Performance win is small and adds
complexity.  Encouraged Alex to experiment with this and other approaches
to deal with same problem.


Next Meetings
- -------------

Need two face to face meetings between now and the next IETF meetings.
Earliest for Deering could be early October.  Probably Boston in October
10, 11, 12.  Then another meeting in November.
1

Document Structure
- ------------------

Discussion of making IPng options in separate documents or in main
document.  Put fragmentation in same document as MTU discovery.  Only put
base options (e-e, hop-by-hop) in main spec.

Neighbor discover will be in this w.g.


User Interfaces Issues / Tony Li
- --------------------------------

Would be nice to use bit count instead of a mask.  Suggested:

    x:x:x:x:x:x:x:x(mm)

where mm is the length of the masks.

Suggestion to not use ":", because it is a shift character.  Other
possibilities include:

     xx'xx'xx'xx'
     xx;ss;ss;ss;
     xx,xx,xx,xx,xx,xx,xx,

Also suggested "..." as compression character.  For example:

xx-xx-xx-xx...xx-xx-xx-xx

Hinden has action to propose something to the list.


Header compression / Bill Simpson
- ---------------------------------

Knows how to do compression over PPP, but now sure how to do it over
SLIP.  Group thought doing PPP for now was fine.  We can defer SLIP work
later (if someone wants to do this).


Closing Thought / Dan McDonald
- ------------------------------

Lets put running code back into "Rough consensus and running code"


 ------------------------------------------------------------------------------
IETF SIPP Working Group - Archives:  parcftp.xerox.com:/pub/sipp
Unsubscribe:	unsubscribe sipp		(as message body, not subject)
Direct all administrative requests to [e-mail]