Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/sipp/sipp-minutes-94jul.txt

Text File | 1994-11-02 | 38KB | 900 lines

CURRENT_MEETING_REPORT_

Reported by Ross Callon/Wellfleet and Bob Hinden/Sun Microsystems

Minutes of the Simple Internet Protocol Plus Working Group (SIPP)

The SIPP Working Group held two working group sessions and one
implementors meeting.  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.


Wednesday

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

Agenda

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


IPng AD Recommendations

   o SIPP header format (with extension headers)
   o 16 byte fixed length addresses
   o SIPP security work
   o Simplified transition (SST)


Open Areas

   o source routing
   o max payload size and minimum MTU
   o auto-configuration and re-addressing
   o authentication and encryption options
   o pseudo-header checksum rules
   o address assignment plan
   o tunneling
   o mobility
   o 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
ISIS 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:


   o 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).

   o Minimum MTU: What are the tradeoffs here?

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

   o 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.

   o 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).

   o 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:


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

   o 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).

   o 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.


   o APIs should be a priority.

   o 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.

   o 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?).

   o 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.


Thursday

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

We discussed the addressing architecture Internet-Draft:

   o 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

   o 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

   o 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:

   o source routing
   o max payload
   o minimum MTU
   o autoconfiguration and readdressing
   o authentication and encryption
   o pseudo-header checksums
   o address assignment

We need to assign names to documents.

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

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



Friday Implementors Meeting


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.



Miscellaneous 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 versus Global Addresses - Alex Conta

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.



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.''