CURRENT MEETING REPORT

Reported by Robert Hinden, Ipsilon Networks

Minutes of the IPNGWG Working Group (ipngwg)

Steve Deering opened the meeting. Bob Hinden agreed to take the minutes. The agenda was reviewed and it was agreed that the following items be discussed:

• Introductions-Steve Deering
• Document Status-Bob Hinden
• University of New Hampshire Bakeoff Report-Jim Bound
• Spec. changes from UNH Experience-Steve Deering
• DHCPv6 Issues-Ralph Droms
• Host Anycasting Support-Jim Bound
• Multihomed Hosts-Mike Shand
• Link Local Address and Interface ID's-KRE
• Payload Header-KRE
• Header Compression for IPv6-Mikael Degermark
• Tunneling Spec-Alex Conta
• Unicast address Formats-Bob Hinden
• Swap Source & Destination Address in IPv6 Header-Mike Carlton
• PMTU Spec-Jack McCann
• BSD API Issues-Bob Gilligan
• UDP + TCP/MSS vs. JumboGrams-Dave Borman
• Host Handling of Router Header
• Max Autoconfig Token size
• Correct ::127.0.0.1 in Transition Mechanism Specification
• IPv6 over PPP-Dimitry Haskin

MONDAY

Document Status / Bob Hinden

Since the last IETF meeting the following IPv6 RFC's were published as Proposed Standards:

• Internet Protocol, Version 6 (IPv6) Specification IP Version 6 Addressing Architecture
• Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification
• DNS Extensions to support IP version 6

The following document was published as an Informational RFC:

• An Architecture for IPv6 Unicast Address Allocation

The following documents was published as an experimental RFC:

• IPv6 Testing Address Allocation

The following document was approved by the IESG to be published as an experimental RFC:

• OSI NSAPs and IPv6

This document was rejected by the IANA because of the usage of the complete portion of the NSAP address space assigned to the IANA. To resolve this, an AFI number is being assigned to the IANA which will give the IANA additional address space. A new draft is being prepared.

The following documents have completed IETF last call and the IESG is considering for evaluation to Proposed Standard:

• Neighbor Discovery for IP Version 6 (IPv6)
• A Method for the Transmission of IPv6 Packets over Ethernet Networks
• A Method for the Transmission of IPv6 Packets over FDDI Networks

The IESG returned the following document to the working group:

• An IPv6 Provider-Based Unicast Address Format (This document was discussed later in this meeting)

The following documents are ready to be sent to the IESG:

• A Method for the Transmission of IPv6 Packets over Token Ring Networks

The following documents are almost ready for IPng Working Group last call:

• Path MTU Discovery for IP version 6
• Generic Packet Tunneling in IPv6 Specification
• IPv6 Program Interfaces for BSD Systems

UNH Bakeoff-Jim Bound

Jim Bound gave a report on the UNH IPv6 Bakeoff. Router implementations were tested from Digital, Ipsilon Networks, and Bay Networks. Host implementations were tested from Sun Microsystems, Mentat, FTP Software, WIDE Consortia, HP, Digital, and INRIA.

Most of the base spec was tested as were Neighbor Discovery and Auto Address Configuration.

The testing went well. The group is planning another test in late June.

Specification Changes/Issues arising from UNH Bakeoff-Steve Deering

• When processing routing header, If packet too big for next hop MTU, send ICMP packet "Pkt too big" to source

Do NOT fragment

• On reception of option with wrong alignment, send ICMP parameter problem.

Discussion about how to move changes forward. Scott Bradner (AD) said a new Internet-Draft should be published, then ask IESG to publish an informational RFC.

• In ND specifcation, clarify purpose and effect of the on-line flag. This is a mechanism which requires that all hosts send to routers to reach all destinations. Erik Nordmark noted that the text describing this topic was clarified in the current version of the ND Internet-Draft.
• Does a redirect for a packet with non-zero flow Ineternet-Draft apply to only that flow or for all packets to same destination? Deering suggested that it should apply to all packets to that destination. Redirection of flows should be done with flow setup protocol (e.g., RSVP). Group agreed to make the IPv6 redirect flow insensitive. Dennis Fergusion noted that a flow redirect would also need to redirect source, destination, flow Internet-Draft, not just destination.
• Discussion on should a host accept new connections on a "depreciated" address. Group concluded that a host should accept new connections on a "depreciated" address. The AddrConf spec should be clarified.

DHCPv6 Issues-Ralph Droms

Authentication/Verification in DHCPv6

Background

• Want to authenticate clients and servers and verify contents unmodified.
• DHCP uses "relay agents" that retransmit messages between client and off-link server.
• DHCPv4 uses "giaddr' and "hops" fields, which are changed by the relay agent.

Proposed Solutions

• Uses IPSEC and tunnels between relay agents and servers.
• Client discovers relay agents, inserts "giaddr" and uses IPSEC
• Skip "giaddr" and "hops" in verification computations with IPSEC orDHCP specific mechanism.
• Use IPSEC with separate associations between client/relay agent and relay agent/server.
• Defer authentication; encrypt response.

Discussion about preferences of each proposed solutions. No clear preference from working group.

Multiple Addresses and DCHCPv6 in IPv6

• Are multiple addresses per interface a good idea for Ipv6: Yes
• Should multiple addresses be delivered "on demand"? Service want its own address, doesn't know it until server starts.
• Long varied discussion about pro's/cons. Straw poll leaning that this is a good idea.
• Will applications want to specify the characteristics of the addressesthey request? Site Local / Global, Life Time, Multi-homed Discussion....... No concensus on this.
• How will applications specify these addresses?
• Should DHCP be charged with specificaton and delivery of multiple addresses?

DHCPv6 will be discussed tomorrow evening DHCP session.

Bob Gilligan, NGTRANS co-chair offered to let the IPng working group use the second half its session on Tuesday to complete more action items. The chairs accepted his offer. An additional session was scheduled Tuesday at 4:30pm at the end of the NGTRANS session.

TUESDAY

Multihomed Hosts

Draft tries to enumerate what multihoming means. Are there issues not described. Lists issues. Author wants people to read draft and have discussion on list and discuss at next IETF meeting. Suggestion to change title to "Multihomed Hosts".

Payload Header

KRE's proposal to support multipayload fields in single packet. Proposal to require implementation of this options. Three advantages: Put a number of small packets in one large one, 2) Makes better use of jumbograms, could be useful for better alignment in supercomputers. 3) Align TCP header on 8 byte boundary.

Choice to to require it or to throw out the option. Meeting in Washington, DC concluded this was not worth doing. Discussion on pros/cons. Would put burden on receiver. Not at all clear how sender would like this to be used. Also, large issue for implementations of firewalls. Firewall would need to look inside to see if there were other headers. Group decided to not pursue.

IPv6 over PPP / Dimitry Haskin

Draft proposal for a new PPP network control protocol to negotiate IP version 6 datagram transmission and configureation options. Current draft is draft-ietf-ipngwg-pppext-ipv6cp-01.txt.

Draft was developed because IPv6 datagram use different protocol ID another data links and has different options than IPv4.

Options are interface token used to form IPv6 link-local address as well as in global address autoconfiguration. Generated similar to Magic Number procedure. Also includes an option for IPv6 compression protocol.

Draft was reviewed by PPP group. IPng needs to approve to move forward.

Interface token:

Discussion about necessity of special PPP compression for IPv6 because there is already a general PPP compression algorithm which is not protocol specific.

Discussion about reducing the size of the interface token. Would make compressions better if there was more zeros in the address. Suggestion for 8 bit interface token. Also, would allow more subnet space to create local address hierarchy in dialup service providers Suggestion for 32bits. Discussion about using smaller token. Group agreed to use 32bit tokens. Document will be revised. Chairs will do a working group last call when new ID is published.

WEDNESDAY

Unicast Address Formats / Bob Hinden

The IESG returned the "An IPv6 Provider-Based Unicast Address Format" <draft-ietf-ipng-unicast-addr-fmt-03.txt> to the working group. The issues dealt with the use of fixed length fields in the middle of the address. A new draft has been issued with attempts to resolve this issue. It defines the format for this address type to be:

In this version of the document the RegistryID uses a 5 bits and the Provider ID and Subscriber ID fields together use 56 bits. Individual subscribers are always guaranteed 64 bits of local address independent of which provider they use to insure operation with addr conf and to allow renumbering.

The working group agreed to do a working group last call on this document and then to advance it to the IESG for proposed standard at the completion of the working group last call.

PMTU Specification / Jack McCann

Author reviewed changes from previous version. These included:

• Add terminology section
• Clarify definition of path
• Local representation of path (implementation specific)
• Applies to Multicast
• Processing routing header
• PMTU for directly connected node
• Note about PTB message with MTU < 576 bytes
• Appendix on changes from RFC-1191
• Add Jeff Mogul as an author
• Remove references to "routes"

Working group agreed to do a working group last call on this document.

Header Compression for IPv6 / Mikael Degermark

Why Header Compressions: On low speed links want good interactive response time. Want to be able to support realtime audio.

Goals to compress IPv6 (and IPv4), TCP, and UDP Headers. No setup is required in this proposal and it works over simplex links. The goal to support realtime audio for low speed links.

Results: Reduces IPv6/UDP headers to 8.7% of size, 48 bytes to 4 bytes. Swedish Institute of Computer Science (SICS) has a prototype implementation running. Compressor is about 400 lines of C code. Decompressor is 300 lines of C code.

Basic idea is to send a full header with a CID (compression ID) occasionally. Subsequent compressed headers carry the CID and fields that are different from the fields in the full header.

TCP uses RFC1144 header. New formats for non-TCP flows. Adds generation field to identify when compression state is obsolete. Supports different formats depending on how much information is carried. Goal is to use the smallest possible.

Handles compression of IPv6 subheaders. Includes rules for how to handle extension headers.

Includes four different ways to classify how an individual field will change. Includes:

• NOCHANGE: Never changes.
• DELTA: Changes in predictable way. Send difference.
• RANDOM: Can not predict, must be included
• INFERRED: Can deduce from other fields. Example of link level field.

Showed examples of different cases are extended.

Full Headers: Don't want to increase the size of a full header when maximum MTU is being used. Utilizes fact that header length field can be inferred. Uses the length field in IPv6 [and transport] header. Assumes that link layer provides the length of the packet. Also assumes that link layer delivers packets in the order that they are sent.

Interesting issue of how to deal with packet loss. What happens if full header (which would have changed compresisons state) is lost. Must be able to detect this incorrect decompression and reestablish compressions state.

For TCP many fields use delta encoding (tcp segements, etc.). If lost, then TCP sequence fields will be off. TCP checksum will catch these packets. Compressor looks for TCP retransmits then sends full header.

Uses softstate for non-TCP packets. Periodically sends full header refreshes. Then does exponential backoffs to reduce the number of full headers sent. This is where generation field is used to establish new compressions state. Cost of sending full headers periodically only increases the average size of packets sent by 1.4 bits.

This scheme can also be used for multicast and non-point to point links.

Authors have not specified how which packets should use specific compressions state. Includes guidelines, but has not specified exactly. There is a tradeoff with how much compressions is done and implementation complexity.

Need a way to tell these different headers apart. Could either get new link layer identifier (e.g., ethertype) or use different values in the version field.

Group will discuss the merits on the ipng mailing list.

SICS plans to make code available for the header compression implementation.

Tunneling / Alex Conta

New draft which includes changes agreed at previous meeting. Also added new section which discusses the dangers of recursive encapsulation.

Other clarifications of document.

Risk factors in Recursive encapsulation

• Type of tunnel
• Type of route to exit point:
• Type of Tunnel

Inner tunnel with identical exit points, can be

• Fixed-exit pints (different entry points)
• Free-Exit inner tunnels (different entry points)

Type of Route

• Route to a specific destination node / minimum risk
• Route to a specific prefix-net / min risk
• Route to an unspecified destination / Default route
  • Default tunnel / Max risk!

Discussion about necessity of need for tunnels in tunnels with same exit point. Desire to show some evidence in practice that there is a real problem to be solved. (cisco systems has similar mechanism in their proprietary tunneling protocol. It would be useful to find out how effective/necessary it has been.)

Suggestion to include mechanism once in a while (one out of n packets).

Group agreed to continue discussion on mailing list.

Proposal to Reorder Addresses in IPv6 Header / Mike Carlton

Might be performance gain when forwarding packets if destination address is before source address. Presented example of how it affects cache in generic machine.

• Must check next header, hop limit, flow label.
• Write new hop limit.
• Validate source address.
• Use destination or flow label to search route cache.
• Upper part of source to determine address type
• Upper part or all of source to route multicast packets.
• Reordering will improve cache performance.
• Assumes FP is no more than 10 bits.
• Cache miss to 10-50 or more processor cycles.

After long discussion, a straw poll was taken and the working group decided to leave the header order the way it was.

This decision was reopened at the end of the session. After another long discussion the group could not make a decision and directed the working group chairs to discuss the issue and make a decision. That was done and the text of the message to the working group documenting this is included here:

Background:

If you attended Wednesday's ipngwg meeting in LA, or if you listened to it over the MBone, you will know that we had a lively discussion about possibly swapping the order of the Source Address and Destination Address fields in the IPv6 header. Several folks argued that changing the address order would allow for faster software forwarding of IPv6 packets in particular implementations (e.g., for particular cache line sizes), and for those implementations where it didn't help, it also didn't hurt to change the order. The potential (but unproven) performance benefit had to be weighed against the less tangible costs of making such a fundamental change at this late state in the process, such as confusion in the implementor community, further delay in progressing the specs, and possible negative "PR" consequences. A poll of the meeting attendees showed no strong consensus one way or the other, but a modest majority were in favor of leaving the order as is. So in my role as chair of the meeting (and co-chair of the WG), I made a snap "ruling" to leave the address order as is. After doing so, I had serious second thoughts. I concluded that I had let non-technical concerns override my best technical judgement (given the information at hand, admittedly incomplete), and that that was inappropriate for the IETF. So at the end of the WG meeting, I said I wanted to change my "ruling" and swap the two address fields. Then things got really animated, and much more vigorous arguments were made for leaving the address order as is. Finally, I conducted another poll, and this time the number in favor and the number opposed to swapping the address were approximately equal (!), with many abstentions. In the face of this clear lack of consensus, the two co-chairs were delegated to make a decision and announce it to the mailing list.

Decision by Deering and Hinden:

*** The order of the addresses in the IPv6 header stays as is. ***

*** That is, source address first, destination address second. ***

Rationale:

1. Swapping the addresses would not be "harmless", performance-wise, in all circumstances, contrary to what I claimed in the meeting. As Tracy Mallory pointed out, for packets with non-zero flow labels, moving the source address after the destination address would force the router to look further into the header than would otherwise be necessary. Thus, on those architectures that benefit from not having to read the whole header, flow-based traffic would be penalized by a change of address order.
2. As Christian Huitema pointed out, necessary improvements in congestion handling for non-flow-based traffic, such as fair queueing or a statistical approximation of fair queueing, are likely to require examination of the full source address of every forwarded packet anyway, in which case moving the source address to the end buys nothing, and defeats the possible gain described in the next point...
3. Assuming adoption of the proposed unicast addressing plan in which the low-order 64-bits of an IPv6 unicast address are used only for intra-site purposes, all inter-site forwarding can be done without looking at the last 64 bits of the destination address. Thus if we leave the address order as-is, we can still exploit the benefit of not fetching the trailing 64 bits of the header for inter-site routing, where the highest throughputs are going to be needed.

Note:

Mike Carlton, who initiated the discussion of swapping the addresses in his presentation on cache effects on IPv6 header processing, agrees with this analysis and has withdrawn his request to change the address order.

Unique Interface ID's / KRE

Proposal to change link link layer address to:

"IID" is long term constant identifier of the interface, unique within the

node.

Notes

Optional: Nodes not required to use these fields.

For Non-Participants

• Minor change to ND discovery procedures

For Participants

• Generate modified LL-ADDR
• Modified DAD
• Need to be able to detect DAD from another local interface (same node)

Modify Draft

• DAD NS Reply (NA)

There was a general concensus to pursue this proposal.