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: ipng@sunroof.eng.sun.com To join, send an e-mail message to: majordomo@sunroof.eng.sun.com 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.''