NOTE: This charter is a snapshot of the 39th IETF Meeting in Munich, Bavaria, Germany. It may now be out-of-date.
Bob Hinden <firstname.lastname@example.org>
Steve Deering <email@example.com>
Internet Area Director(s):
Jeffrey Burgan <firstname.lastname@example.org>
Thomas Narten <email@example.com>
Internet Area Advisor:
Jeffrey Burgan <firstname.lastname@example.org>
General Discussion: email@example.com
To Subscribe: firstname.lastname@example.org
In Body: in body: subscribe ipng
Description of Working Group:
Editor: Bob Hinden (email@example.com)
The next generation of the Internet Protocol (IPv6) is intended to support Internet traffic for many years into the future by providing enhancements over the capabilities of the existing IPv4 service. This working group will produce specifications for the core functionality of that service. The working group shall carry out the recommendations of the IPng Area Directors as outlined at the July 1994 IETF and in ``The Recommendation for the IP Next Generation Protocol,'' Internet-Draft, (draft-ipng-recommendation-00.txt), September 1994.
The working group shall use the following documents as the basis of its work:
· Simple Internet Protocol Plus (SIPP) Specification (128 bit version)
· SIPP Addressing Architecture
· An Architecture for IPv6 Unicast Address Allocation
· Simple SIPP Transition (SST) Overview
· SIPP Program Interfaces for BSD Systems
· SIPP Security Architecture
· SIPP Authentication Header
· SDRP Routing Header for SIPP-16
· IP Next Generation Overview
· ICMP and IGMP extensions for SIPP
· FTP Operation Over Big Address Records (FOOBAR)
· DNS Extensions to support SIPP
Enhancements to be considered:
· Large Packets: Consider extensions for support of datagrams which are larger than 64K.
· Source Routing: The working group shall consider enhanced source routing capabilities for IPng.
· Tunneling: Complete specification of IPng in IPng tunneling.
· Address format and assignment plan: The working group shall review the details of address structure as specified in [SIPP-16] and shall repair any deficiencies with respect to current or near-term addressing requirements, assuming a fixed, 16-byte size. The specification shall provide a mechanism for supporting multiple additional formats, for possible enhancement to incorporate other popular addressing schemes.
· Routing Structure: In completing the addressing details, the working group shall ensure that routing according to current, CIDR-like schemes can be supported comfortably.
· Autoconfiguration: Coordinate with the IPng Address Autoconfiguration Working Group.
· Transition: The working group shall coordinate with the related transition and conversion efforts (ngtrans, tacit, nosi, etc.) to ensure that the base specification provides the facilities required for the transition from IPv4.
· Security: A set of base documents for IPng security shall be completed. This shall include algorithms for authentication and privacy carried as IPng extension headers and include an initial selection of required encryption and key management algorithms and a facility to support other optional algorithms. The working group should also examine IPng firewall issues and if necessary develop specific firewall frameworks.
· Minimum MTU: Consider a larger minimum MTU.
· Header Compression: Consider ways to abbreviate the IPng header in the contexts of native IPng, multiple IPng packets in a flow, and encapsulated IPng.
· TCP/UDP: The IPng Working Group will specify the procedures for hosts to compute and verify TCP/UDP pseudo-headers. Any other changes to TCP beyond making TCP work with IPng are out of scope of the working group and should be dealt with by a TCPng Working Group.
The IPng Working Group will coordinate with other groups, including Mobile IP, IPng Address Autoconfiguration, OSPF, IS-IS, RIPv2, IDR, Security, Applications, Network Management, IP over ATM, etc.
Goals and Milestones:
Submit preliminary IPng core specifications, with required enhancements, as Internet-Drafts.
Submit revised core IPng specifications as Internet-Drafts.
Submit core IPng specifications to IESG for consideration as Proposed Standards.
Submit extended IPng specifications as Internet-Drafts.
Submit extended IPng specifications to IESG for consideration as Proposed Standards.
Submit revised specifications to IESG based on implementation experience for consideration as Draft Standards.
Submit revised IPng specifications as Internet-Drafts.
Submit final IPng specifications to IESG for consideration as Standards.
Submit revised specifications to IESG for Proposed Standard. Includes Aggregatable Unicast Formats, IPv6 over Ethernet, IPv6 over FDDI, IPv6 over Token Ring, IPv6 over PPP, Header Compression, etc.
Submit updated core IPng Specifications to IESG for Draft Standard. Includes: Protocol, Addressing Architecture, Addressing Documents, ICMP, Neighbor Discovery, Address Auto Configuration, DNS, etc.
Submit IPng specifications at Proposed Standard to IESG for advancement to Draft Standard.
Submit IPng specifications at Draft Standard to IESG for advancement to Standard.
· Generic Packet Tunneling in IPv6 Specification
· Link Local Addressing and Name Resolution in IPv6
· IPv6 Router Alert Option
· IPv6 Multicast Address Assignments
· IP Version 6 over PPP
· Management Information Base for IP Version 6: Textual Conventions and General Group
· Management Information Base for IP Version 6: ICMPv6 Group
· Management Information Base for IP Version 6: UDP and TCP Groups
· GSE - An Alternate Addressing Architecture for IPv6
· Transmission of IPv6 Packets over FDDI Networks
· Transmission of IPv6 Packets over Ethernet Networks
· Synthesis of Routing Goop and AAAA Records in IPv6
· IP Version 6 Addressing Architecture
· Separating Identifiers and Locators in Addresses: An Analysis of the GSE Proposal for IPv6
· Router Renumbering for IPv6
· An IPv6 Aggregatable Global Unicast Address Format
· IPv6 Testing Address Allocation
· IP Version 6 Management Information Base for the Transmission Control Protocol
· IP Version 6 Management Information Base for the User Datagram Protocol
· Transmission of IPv6 Packets over Token Ring Networks
· TLA and NLA Assignment Rules
· IPv6 Name Lookups Through ICMP
· Neighbor Discovery for IP Version 6 (IPv6)
· IPv6 Stateless Address Autoconfiguration
· Internet Protocol, Version 6 (IPv6) Specification
· Site prefixes in Neighbor Discovery
Request For Comments:
DNS Extensions to support IP version 6
Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6)
IP Version 6 Addressing Architecture
An Architecture for IPv6 Unicast Address Allocation
IPv6 Testing Address Allocation
Path MTU Discovery for IP version 6
Neighbor Discovery for IP Version 6 (IPv6)
A Method for the Transmission of IPv6 Packets over Ethernet Networks
OSI NSAPs and IPv6
Transmission of IPv6 Packets Over FDDI
IP Version 6 over PPP
An IPv6 Provider-Based Unicast Address Format
Basic Socket Interface Extensions for IPv6
TCP and UDP over IPv6 Jumbograms
Minutes of the IPng Working Group Meeting
Chaired by Steve Deering, Cisco and Bob Hinden, Ipsilon.
Reported by Bob Hinden.
Introduction / Deering, Hinden (5 min)
Action Items / Hinden (5 min)
Document Status / Hinden (10 min)
Plan for Advancing Current Drafts / Hinden ( 10 min)
IPv6 Protocol Updates / Deering (30 min)
- Restrictions on Routing header reversal
- Specification of Class (formerly Priority) field
- Reserved bits for Explicit Congestion Notification bits
- Inclusion of Class in Flow constant fields?
- Neighborness rules for Strict/Loose Bit Map
- Encoding of Option types
TLA/NLA Assignment Rules / Hinden (20 min)
Neighbor Discovery Issues / Nordmark, Narten (20 min)
Decision on Advancing Current Documents / Hinden (10 min)
Mobile IP / Johnson (10 min)
IPv6/NBMA work in the ION group / Armitage (10 min)
IPv6 Transmission over Frame Relay / Conta (5 min)
IPv6 Transmission over IPv6/IPv4 Tunnels / Conta (5 min)
Inverse Neighbor Discovery for IPv6 / Conta (5 min)
Inverse Neighbor Discovery for IPv6/IPv4 Tunnels / Conta (5 min)
Site prefixes in Neighbor Discovery / Nordmark (10 min)
Router Renumbering / Crawford (10 min)
IPv6 Name Lookups Through ICMP / Crawford (10 min)
DNS Alternatives to ICMP Name Lookups / Gudmundsson (5 min)
Header Compression / Degermark (10 min)
Traceroute using hop-by-hop options / Durand (5 min)
DHCP vs. Prefix changes
I. Introduction / Deering, Hinden
Steve Deering introduced the meeting and reviewed the agenda.
II. IPv6 Testing Event / Deering
Fifteen companies attended (up from 12). They were Digital, IBM, Sun Microsystems, FTP Software, Fujitsu, Hitachi, Bay, 3COM, Epilog, Toshiba, BSDI, Process Software, Ipsilon, SGI, and Inria.
Testing included 11 host and 6 routers implementations (3 hosts did routing too). They did interoperability testing only, not conformance testing.
· 15 nodes supported ping
· All nodes supported new (aggregatable) address format
· 3 nodes did Path MTU discovery and Packet too big, 6 did not, rest unknown.
· 7 nodes did both client and server telnet
· 6 nodes did client and server FTP
· 2 nodes did PPP
· 3 Routers sent ICMP redirects, 5 hosts processed them correctly
· 5 1/2 hosts did auto-configuration
· A few nodes supported FDDI and/or token ring
Next event is first week in December.
III. Action Items / Hinden
Action Items (San Jose IETF)
· Document editor will submit Tunneling Spec to IESG for proposed standard.
- Sent request to IESG on 12/10/96. IESG last call sent on 12/30/96, which ended on 1/17/97. Many comments received. IESG restarted last call for this document and two GRE documents on IPv4 tunneling.
- Steve Deering currently reviewing GRE documents and will respond to IESG last call. On Agenda for Memphis.
- IPng Chairs sent email to Internet ID's. Waiting for IESG action.
- Jeff Burgan (Internet AD) reported that IESG would vote on this document separately from IPv4 tunneling documents.
· Document editor will do a working group last call on Header Compression specification.
- Sent on 12/10/96. Working group last call ended 12/24/96.
- Comments received from Thomas Narten. Once comments resolved (and new draft published) document editor will send to IESG.
- New Internet Draft Published. On agenda for Thursday session.
· Dimitry Haskin and Dave Katz to write a draft proposing adding an option to BGP4 to carry IPv6 interdomain routes.
- Drafts written for BGP4+ and BGP5. IDR discussed. Compromise discussions underway.
- Discussed at Tuesday IDR session. Consensus to go forward with BGP4+.
· Thomas Narten to include in next version of neighbor discovery rule to silently drop non-DAD packets which use the unspecified address as the source of the packet.
- On agenda for Wednesday session.
Action Items (Interim Meeting)
· "WhoAreYou" ICMP Message / Matt Crawford
- Draft missed ID deadline. Sent to IPng list and on Memphis agenda.
- On agenda for Thursday Session.
· Modify Link Name Draft / Dan Harrington
- Update underway
- Waiting for outcome of "WhoAreYou" draft
· Lessons from interim meeting / Thomas Narten, John Stewart, Allison Mankin, Lixia Zhang, Matt Crawford
- Done. Internet Draft published. Discussion on agenda.
- New draft published. Publish as Informational RFC?
- Authors plan to publish as RFC.
Action Items (Memphis IETF)
· Issue working group last call for IPv6 MIB's once new drafts are published.
- W.G. last call completed.
- Sent to IESG for Experimental, Internet AD's reviewing.
- Jeff Burgan (Internet AD) reported that it will be considered for proposed standard. Need to get a code-point outside of the experimental subtree.
IV. Document Status / Hinden
· RFC - Proposed Standard
- TCP and UDP over IPv6 Jumbograms (RFC2147)
· IETF Last Call completed
- Generic Packet Tunneling in IPv6 Specification
· Submitted to IESG for Proposed Standard
- IPv6 Router Alert Option
· Submitted to IESG for Informational
- Advanced Sockets API for IPv6
· Submitted to IESG for Experimental
- MIB for IPv6: ICMPv6 Group
- MIB for IPv6: TCP
- MIB for IPv6: Textual Conventions & General Group
- MIB for IPv6: UDP
· Working Group Last Call Completed
- Header Compression for IPv6
- IPv6 Router Alert Option
- A Method for the Transmission of IPv6 Packets over ARCnet Networks
- An IPv6 Aggregatable Global Unicast Address Format
- IP Version 6 Addressing Architecture
- IPv6 Multicast Address Assignments
- IPv6 Testing Address Allocation
- TLA and NLA Assignment Rules
- Transmission of IPv6 Packets over Ethernet Networks
- Transmission of IPv6 Packets over FDDI Networks
V. Plan for Advancing Current Drafts / Hinden
Hinden talked about it is now time to move the base IPv6 specifications to Draft Standard. The main criterion is that they are stable. After some discussion with the Internet AD's the important thing is that we don't make any changes which break interoperability. Once a document is at Draft Standard it will be important to not make changes that are not critical. It is important that we stabilize the documents to encourage products and deployment.
With each document we wish to move to Draft Standard an implementation report will have to be written. The document editor will coordinate the creation of a feature list for each specification with the authors and create a template for an implementation report.
The list of documents with a proposal for advancement is as follows:
Document Current Proposal______
IPv6 Protocol Proposed Std. Draft Std.
Addressing Architecture Proposed Std. Proposed Std.
ICMP Proposed Std. Draft Std.
DNS Proposed Std. Draft Std.
Neighbor Discovery Proposed Std. Draft Std.
Address Auto Configuration Proposed Std. Draft Std.
Aggregatable Addresses Internet Draft Proposed Std.
IP_over_Ethernet Proposed Std. Proposed Std.
IP_over_FDDI Proposed Std. Proposed Std.
IP_over_PPP Proposed Std. Proposed Std.
IP_over_ARCnet Internet Draft Proposed Std.
TLA/NLA Assignment Rules Internet Draft BCP
Testing Address Allocation Experimental Experimental
Multicast Assignments Internet Draft Informational
Path MTU Discovery Proposed Std. Draft Std.
Packet Tunneling Internet Draft Proposed Std.
This list will be reviewed later in the meeting after the current drafts are discussed.
VI. IPv6 Protocol Updates / Deering
Restrictions on Routing header reversal
Question about need for requiring RH reversal. Currently, three legal behaviors: reply without a source route, reply with a configured source route (independent from received source route), or reverse received source route if packet was successfully authenticated. Current text is compatible with current Mobile IPv6 draft. Group agreed to keep current behavior.
Specification of Class (formerly Priority) field
4 4 24
| ver | class | flow label |
Bits are available for rewriting by routers. High order class bit recommended for interactive, other three are not defined, but left open for experimentation. These bits and flow label are not included in IPSEC AUTH header.
Reserved bits for Explicit Congestion Notification bits
Deering proposed congestion experienced bit (like "DEC" bit in CLNP). Has been lobbied for many years. Idea is to mark packets when congestion occurs to notify the receiver instead of just dropping packets. Van Jacobson had always resisted idea. At last End-to-End meeting, group came up with approach to use this bit with RED algorithm. Unfortunately, VJ liked the new idea (not so bad). It is too
early to be a required part of IPv6. Does show lots of potential. Thinking about freeing up more bits to allow this usage. Proposes:
4 8 20
| ver | class | flow label |
The class bits would be set to zero on sending and ignored on reception. Reduces number of flows to ~1,000,000 per source address.
Group agreed to make class field 8 bits long. Discussion about how tightly they should be defined. Deering thinks it is important to keep these bits reserved to allow IPv6 to be extensible.
Suggestion to only reserve bits and make definition of usage in a separate document. Christian Huitema disagreed, he thought it should be defined.
Deering thought we should move the definition to a separate document. Group agreed to do this.
VII. Inclusion of Class in Flow Constant Fields?
Question is: must the Class bits be constant for all packets in the same flow? One side of argument is that as long as the Class bits can affect routing, they should be constant within a flow -- otherwise, opportunistic flow set-up can violate desired routing semantics. The other side is the desire not to eliminate the potential flexibility of allowing applications to vary some of the Class bits within a single flow.
Allison Mankin suggested we might delete opportunistic flow setup text. This would be reasonable when going to draft standard.
Choices are to take class out of flow definition, or to define that the "D" bit is not to affect routing.
Group agreed to remove opportunistic behavior from specification, and to exclude Class from set of fields that must be constant within a flow. There are no known current implementations of opportunistic flow setup.
VIII. Neighborness Rules for Strict/Loose Bit Map
Specification never defined Neighborness rules for strict/loose source behavior. Deering speculated that this was included in IPv4 was for security behavior. To keep this behavior it would require adding detailed rules for tunnel behavior, etc.
Suggestion was made that we should get rid of strict source route capability.
D. Hasken thought we should keep strict, but would need consistent set of rules. Deering polled group. Consensus to remove strict bits. Bits become zeros and text-describing usage is removed.
Further discussion, but no change of consensus.
IX. Encoding of Option Types
Should IPv6 option be identified by full 8-bit value or 5-bit option type? Current spec shows full 8-bits. No objections from group.
Change recommended order of Extension Headers.
Deering had changed order based on what he thought was in ESP and AH drafts. This change was in error, and will be changed back to original behavior.
Suggestion to make options fixed length to make it easier to implement IPv6 in hardware. Deering replied that this would also require removing all extension headers. There was a consensus to not make this change.
X. Bigger MTU?
Should we change the IPv6 minimum MTU to something closer to 1500 (i.e., something like 1300, to allow room for one or two levels of encapsulating/tunnel overhead without exceeding the Ethernet MTU of 1500). This is the last opportunity to make this change, given the increasing number of existing implementations and the strong desire to move the base IPv6 spec to Draft Standard ASAP. This change would significantly reduce the importance of doing MTU discovery for multicast, which is something best avoided because of the ICMP implosion hazard. 576 was chosen because of IPoverAppletalk. Most links (except for dialup) are already ~1500. Comment that this would be a problem for dialup links. Deering replied that for slow-speed links it's preferable to do link-specific fragmentation and reassembly, below the IP layer. Several people supported the idea.
Very strong consensus to raise MTU to ~1300 bytes.
Editors Note: The Integrated Services over Specific Link-layers (ISSLL) working group is currently developing standards for doing link-specific fragmentation. Some of their techniques address criticisms of using large MTUs on slow links (e.g., having small packets get stuck behind bigger ones). This may be relevant to this issue.
Deering reported continued issue with decision to increase MTU. Proposes to discuss on mailing list. Need to resolve quickly.
Note: Alex Conta said that ICMP spec needs to get changed for multicast group membership messages. Deering proposes removing multicast membership messages from this document and create a new document for these messages.
I. Proposal to Add Explicit Congestion Notification (ECN) to IPv6 and to TCP / Sally Floyd
Reference: Floyd, S., TCP and Explicit Congestion Notification, ACM
Computer Communication Review, V. 24 N. 5, October 1994, p. 10-23., http://www-nrg.ee.lbl.gov/
What is New
· Deployment of active queue management (e.g., RED) in the internet.
· Increasing amount of best-effort traffic where the user is sensitive to the delay (due to retransmission) or drop of an individual packet (e.g., telnet, web browsing, best-effort audio and video, etc.
What is Needed in IPv6?
· Two bits:
- An ECN-capable bit set by the origin transport protocol
- An ECN-bit set by the router (instead of dropping the packet) when the buffer has not overflowed, and the ECN-capable bit is set, and the router would otherwise drop the packet because of the RED algorithm, based on the average queue size.
· There is a single-bit version of this, described in Floyd94, that overloads a single bit
What does ECN Bit Indicate?
· Indicates incipient congestion as indicated by the "average" queue size exceeding a threshold, using the RED algorithms [FJ93, RED-ietf-draft]
· The ECN bit should "not" be set in response to an unfiltered signal such as the instantaneous queue size.
· A "single" packet with the ECN bit set should be treated by the end-nodes as an indication of congestion, just as would a "single" dropped packet.
How do transport protocols respond to the ECN bit?
· Congestion control response should be the same as that to a dropped packet.
· Details depend on specific transport
- Reliable unicast (e.g., TCP)
- Reliable multicast (e.g., SRM)
- Unreliable unicast
- Unreliable multicast (e.g., vic)
What modifications are needed for TCP?
· Negotiation between the endpoints during setup to determine if they are both ECN-capable
· A TCP option with an ECN-Notify bit so that the data receiver can inform the data sender when a packet has been received with the ECN bit set.
· The data sender halves its congestion window "cwnd" in response to an ECN-notify. This is done only once per window of data.
Internet draft will be out in a few weeks.
II. TLA/NLA Assignment Rules / Hinden
· Goal to Provide Guidance to Registries and Organizations receiving TLA IDs
- Avoid "Land Rush" on TLA IDs
· Focus on assigning TLA IDs to Organizations providing Public Transit Service
· Assignment does NOT mean ownership
- It implies "stewardship"
TLA Assignment Rules:
· Must have a plan to offer public native IPv6 service within 6 months from assignment. The plan must include plan for NLA ID allocation.
· Must have a plan or track record of providing public Internet transit service on fair, reasonable, and non-discriminatory terms, to other providers. TLA IDs must not be assigned to organizations that are only providing leaf service even if multihomed.
· Must provide registry services on fair, reasonable, and non-discriminatory terms, for the NLA ID address space it is responsible for under its TLA ID. This must include both sites and next level providers.
· Must provide transit routing and forwarding to all assigned TLA IDs on fair, reasonable, and non-discriminatory terms.
· Organizations are not allowed to filter out any specific TLA Ids (except temporarily for diagnostic purposes or emergency repair purposed). Periodically (interval set by registry) provide to registry utilization statistics of the TLA ID it has custody of. The organization must also show evidence of carrying TLA routing and transit traffic. This can be in the form of traffic statistics, traceroutes, routing table dumps, or similar means.
· Erik Nordmark: don't rule out tunnels for TLA access (e.g., for hopping over non-IPv6-supporting secondary provider).
· Brian Carpenter: The wg's responsibility is to specify technical proposal and the technical rationale/justification
· Steve Deering: Gov't example is special case of an ISP that serves a closed community
· Someone: please don't use word "rules". Too strong. Internet AD's will help wordsmithing.
· General consensus to move forward as a BCP when new draft is out incorporating suggested clarifications. An IETF last call will be useful to have the broader IETF community review the idea in this document.
III. Neighbor Discovery Issues / Nordmark
· Change move solicited node MC address changed to pointer to Address Arch.
· Remove priority references
· Decrementing lifetime variables
· Default lifetime infinity changed to 60 days
· Use of unspecified source
· Setting of NUD state
· Setting of Ls router flag
· Added "renumbering considerations" section
The zero lifetime issue is still unresolved. This is the remaining issue that needs to be resolved before moving ND and AddrConf to Draft Standard. The authors will make a proposal on the mailing list.
IV. Decision on Advancing Current Documents / Hinden
- Group agreed to move to Draft Standard once the MTU issue was settled.
- Group agreed to move to Proposed Standard.
- Group agreed to move to Draft Standard once multicast membership messages were removed.
- No action at this time. Waiting for resolution of other DNS related work.
- No consensus to move this forward. Zero lifetime issue still open.
Address Auto Configuration
- No consensus to move this forward. Zero lifetime issue still open.
- Group agreed to move to Proposed Standard.
- Group agreed to move to Proposed Standard.
- Group agreed to move to Proposed Standard once bridging text was removed.
- Group agreed to move to Proposed Standard once terminology was clarified.
- Group agreed to move to Proposed Standard once terminology was clarified.
TLA/NLA Assignment Rules
- Group agreed to request publication as a BGP once revision available.
Testing Address Allocation
- Group agreed to move to Experimental.
- Group agreed to move forward as either Informational RFC or IANA database input.
Path MTU Discovery
- Group agreed to move to Draft Standard.
- IESG will consider for Proposed.
V. Mobile IP / Johnson
Status of IPv6 Mobile work.
· Current spec is <draft-ietf-mobileip-ipv6-03.txt>.
· High Level Overview
- Care-of addresses from IPv6 address autoconfiguration
- Mobile node sends its own Binding Update
- Uses for correspondent nodes and home registration
- Nodes cache bindings in a Binding Cache
- Correspondents route own packets directly to mobile node
· One implementation almost available.
Dynamic Home Agent Address Discovery
· Mobile node may not always know its home agent address
- While mobile node is away from home
- Home network may need to be reconfigured
- Different machine may take over as home agent
· In Mobile IPv4, this is solved by
- Mobile node can send to "directed broadcast" address
- All home agents in home network receive request
- All reject, giving their own unicast address
- Mobile node tries again with one of these addresses
· Can't do this in Mobile IPv6 since no broadcast in IPv6
New Home-Agents Anycast Address
· To register when don't know own home agent address
- Mobile node sends Binding Update to "Home-Agents anycast address" for home subnet
- Receiving home agent replies, giving unicast address
- Mobile node registers to that IP address
- All IPv6 home agents MUST support this
Deering suggested that we reserve some number local interface identifiers for anycast addresses for applications that need anycast addresses.
Suggest a new document for initial anycast assignments. ACTION: Document Editor.
Replay Protection for Binding Updates
· Must guard against replay attacks on Binding Updates
· IPsec AH and ESP can do replay protection
- Protection based on sequence number
- Must re-key before sequence number wraps around
- Only accept packet if sequence number >= max or within a "replay window" of sequence numbers before that
- Allows out-of-order delivery
· Problem: Binding updates MUST be applied ONLY in order
Solution for Binding Updates
· Use IPsec for "Replay Protection"
- Lets IPsec worry about re-keying before wrap around
· Use our own sequence number for sequencing
- Similar to TCP sequence number when using IPsec replay protection
- Our sequence number only needs to be large enough to cover replay protection window reordering.
Getting through Ingress Filtering
· Original Mobile IPv6 addressing for packets sent from a mobile node
- Source address = mobile node home address
- Destination address = correspondent node address
- Problem: Ingress filtering drops all these packets
· New solution uses "Home Address" destination option
- All IPv6 nodes MUST support receiving packets containing a Home Address option.
Questions about how this works and if it affects FTP and telnet. Document will be clarified.
Use of Home Address Option
· Mobile node uses care-of address as source address...
· But only while packet on its way to the destination node
· At the Sender
- Sender builds packet (e.g., TCP) using home address
- Then substitutes care-of address as source
- Move home address into a Home Address option in packet
· At the Receiver
- Receiver substitutes correct source address (home address) back into packet in place of care-of address
· Implementation of this would be required in all IPv6 receivers
Home Address Option vs. Binding Update Option
· Binding Update option
- Creates state in receiver in Binding Cache
- Used by receiver for sending future outgoing packets
- MUST be authenticated
- Use is only an optimization (not required in all nodes)
· Home Address option
- Creates NO state in receiver
- Does NOT affect future routing of any packets
- Need NOT be authenticated (unless IPv6 header already is)
- Receiving MUST be supported by ALL IPv6 nodes
Home Address Option Security
· If IPv6 header "source address" is authenticated
- Home Address option MUST also be authenticated
- Need to preserve protection of this field
- Home address option need NOT be authenticated either
- IPv6 header source address may be forged/modified
- So may Home Address option data
Movement Detection Timing
· Helpful to know when to expect packets from router
- Mobile node know when it missed one
- Mobile node can decided for itself home many missed packets are a cause for concern (possible movement)
· Neighbor discovery provides good source of packet form router
- Periodic Router Advertisements
- Must receive new one before old one expires
- But router must send more frequently, since some might be dropped
- Would help mobile node to know nominal advertisement interval
- Example: long lifetimes, but frequent advertisements
· Send comments to mobile IP mailing list <firstname.lastname@example.org>
· Also can be sent to Dave Johnson <email@example.com> and Charlie Perkins <firstname.lastname@example.org>
VI. IPv6/NBMA Work in the ION Group / Armitage
Current draft is: <draft-ietf-ion-tn-01.txt>
Suggestion to put "ipv6" in name of draft
· Interface token now based on 8 octet EUI-64
· Cleaned up vague text
· Specified host triggered transient neighbor discovery
· Folded in some text from expired <draft-ietf-ion-ipv6nd>
· Syntax mapping between ND and NHRP at routers
· Clean up the misleading "ATM dependency" implied by current text
· "on link" => "on logical link" (on LL)
· ND used on LL (native multicast or augmented MARS/RFC2022)
· Flow detection in router leads to NHRP query for destination
- NHRP reply translated to Redirect on source LL
- "transient" neighbor
· Host Trigger (NS for remote dst sent to router) also leads to NHRP inter-router query
· NHRP reply translated into NA back to soliciting host
Current approach does not require ND to change.
Questions to email@example.com
VII. IPv6 Transmission over Frame Relay / Conta
· Min, max, default MTU
· Frame format for IPv6 over FR
· Interface ID for FR interfaces
· IPv6 local address
· Source/target link layer address options in ND
· Min frame size, 5,6, or 7 octets
· General requirement for at least 262 octets
· IPv6 requires a minimum MTU size of 576
· Default MTU = 1600
· 575 <= MTU <= 4080 with CRC16
· MTU > 4080 less error detection / correction at link layer
· MTU defined per link - implementation limitation.
Deering comment need strong link layer CRC. Should discourage MTU greater than 2080.
Frame Format using SNAP identifier. Found out there is a NLPID (0x8E), would save same header bits.
Slides showing figures with two approaches to create Interface IDs (first includes FR Node Identifier, FR Link Identifier, and FR DLCI, second is random number and FR DLCI), Link Local address, and Unicast Address Mapping.
Editors Note: After discussion with the author and the chairs of the ION working group, the IPng chairs decided that the ION working group should own this topic. The IPng working group will consulted to insure that the work is consistent with IPv6.
VIII. IPv6 Transmission over IPv6/IPv4 Tunnels / Conta
Extension to existing IPv6 tunneling document
· Tunnel minimum, maximum, and default MTU
· Frame format for IPv6 over IPv6 and IPv4 tunnels
· Interface ID for IPv6 tunnel interfaces
· IPv6 link-local addresses for tunnel virtual links
· Source/Target Link-layer address option used in ND or IND over IPv6 and IPv4 tunnels.
· Default tunnel MTU is Physical underlying IPv6 interface MTU - tunnel headers size
· 576 <= tunnel MTU < default tunnel MTU
Tunnel Packet Format
· IPv6 tunnel packets re encapsulated as IPv6 and IPv4 packets
Interface ID (IPv6 tunnels only)
· The IPv6 tunnel pseudo-interface ID
- Unique on the virtual link represented by the tunnel
- Based on the underlying physical interface identifier
· Mask the forth and fifth octets of the EUI-64 identifier with the fixed 0xFFFC value
- Example: 36-56-78-FF-FE-9A-BC-DE becomes 36-56-78-FF-FC-9A-BC-DE
Link Local Address
· The IPv6 link-local address for an IPv6 tunnel interface is formed by appending the interface token, as defined above, to the prefix FE80::/64.
Address Mapping [figure not included]
IX. Inverse Neighbor Discovery for IPv6 / Conta
Draft is <draft-conta-ipv6-nd-ext-inv-00.txt>
Introduced topic. Extension to IPv6 for FR and similar links when link layer is known, but IPv6 address is not known. Read document and send comments to author <firstname.lastname@example.org>.
X. Inverse Neighbor Discovery for IPv6/IPv4 Tunnels / Conta
Draft is <draft-conta-ipv6-inv-nd-tun-00.txt>
Introduced topic. Extension to ND to allow inverse discovery for tunnels to aid in tunnel configuration. Read document and send comments to author <email@example.com>.
XI. Site Prefixes in Neighbor Discovery / Nordmark
Includes automatic creation of site local addresses and the creation of global version for DNS lookup. Only global addresses need to be in the DNS.
Motivation / Requirements
· Reduce the risk of renumbering a site
· Ensure that communication local to a site uses site-local addresses
· Do not require that sites use a two-faced DNS (i.e., do not store the site-local addresses in the DNS).
[Slide with additions to ND Prefix Option]
· Create site-local addresses when an address returned by DNS matches a site prefix. The first Site PLength bits are taken from the site-local address (FEC0::0) and the remaining bits are taken from the returned address.
· Add the created site-local addresses to the front of the list returned to the application.
· Hidden from applications (i.e., in gethostbyname library).
Name Lookup Example
· Name service returns (for a multihomed node)
· List of Prefixes
· Resulting list of addresses (duplicates removed)
· No change unless a site-local address
· For site-local form the potential global addresses using the prefix list and the site-local address
· For example, if the site-local address is:
· List of site prefixes
· The addresses that should be tried
· Node on link can be use this to spoof the address and names returned by the DNS.
- But such a node can already intercept all traffic
- Doing name/address lookup without communicating
· Subnet number must be the same for all global and site-local addresses used by the site. Is this too strict?
· Should the formed site-local address replace (instead of being added to) the global addresses returned to the application.
· Common API to access the list of site prefixes.
Many questions. Need additional discussion on the list. We need to discussion on the mailing list.
XII. Header Compression / Degermark
Main draft: <draft-degermark-ipv6-hc-03.txt
Negotiate for PPP: <draft-engan-ip-compress-01.txt>
How to compress RTP: <draft-ietf-avt-crtp-xx.txt>
· Protocol ID's from PPP ext
· Negotiation of header compression parameters
· Name Change: Header Compression for IP
· Changed the order of the field in compressed TCP headers to conform with RFC1144
· Priority/Class field: How to deal with this when we go to Proposed Standard?
· MTU: Not problematic for PPP. There is a standard for link-level fragmentation.
ACTION: Document editor will do WG last call once new draft is available.
DHCP vs. Prefix changes
Issue is nodes can get addresses through manual config, addr conf, and DHCP. If you have gotten addresses from one method, how to deal with changes received from DHCP and/or ADDR CONF. This needs clarification.
One possible rule is that changes only apply based on way they were learned. This is consistent to how DHCP works now for IPv4 (dynamic from DHCP and manual config) and how routing protocols work with dynamic routes vs. static routes. ND and DHCP specs need minor revision.
XIII. DNS Alternatives to ICMP Name Lookups / Gudmundsson
IPng DNS, and DNS
Provide an alternative to "WHO ARE YOU" message.
This is a change from the plan to always return AAAA records. This would return two pieces and host would put together. Claim made that for secure DNS it is necessary to return two pieces.
Needs to be discussed further on the mailing list. This affects moving the DNS draft to "Draft Standard". This needs to be resolved first.
At this point the session ran out of time. The following agenda topics were not discussed:
· Router Renumbering / Crawford
· IPv6 Name Lookups Through ICMP / Crawford
· Traceroute using hop-by-hop options / Durand
The IPng chairs apologize to speakers for not covering their topics at this meeting.
IPng - Agenda, Action Items, and Documents
Ipng - Site Prefixes in Neighbor Discovery
go to list