2.3.10 IPNG (ipngwg)

NOTE: This charter is a snapshot of the 39th IETF Meeting in Munich, Bavaria, Germany. It may now be out-of-date.


Bob Hinden <hinden@ipsilon.com>
Steve Deering <deering@cisco.com>

Internet Area Director(s):

Jeffrey Burgan <burgan@home.net>
Thomas Narten <narten@raleigh.ibm.com>

Internet Area Advisor:

Jeffrey Burgan <burgan@home.net>

Mailing Lists:

General Discussion: ipng@sunroof.eng.sun.com
To Subscribe: majordomo@sunroof.eng.sun.com
In Body: in body: subscribe ipng
Archive: ftp://playground.sun.com/pub/ipng/mail-archive

Description of Working Group:

Editor: Bob Hinden (hinden@eng.sun.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.

Aug 97


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.

Aug 97


Submit updated core IPng Specifications to IESG for Draft Standard. Includes: Protocol, Addressing Architecture, Addressing Documents, ICMP, Neighbor Discovery, Address Auto Configuration, DNS, etc.

Jan 98


Submit IPng specifications at Proposed Standard to IESG for advancement to Draft Standard.

Jun 98


Submit IPng specifications at Draft Standard to IESG for advancement to Standard.


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

Current Meeting Report

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)

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.

Results were:

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

· Document editor will do a working group last call on Header Compression specification.

· Dimitry Haskin and Dave Katz to write a draft proposing adding an option to BGP4 to carry IPv6 interdomain routes.

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

Action Items (Interim Meeting)

· "WhoAreYou" ICMP Message / Matt Crawford

· Modify Link Name Draft / Dan Harrington

· Lessons from interim meeting / Thomas Narten, John Stewart, Allison Mankin, Lixia Zhang, Matt Crawford

Action Items (Memphis IETF)
· Issue working group last call for IPv6 MIB's once new drafts are published.

IV. Document Status / Hinden

· RFC - Proposed Standard

· IETF Last Call completed

· Submitted to IESG for Proposed Standard

· Submitted to IESG for Informational

· Submitted to IESG for Experimental

· Working Group Last Call Completed

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.

Thursday Session

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:

· 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

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

· Focus on assigning TLA IDs to Organizations providing Public Transit Service
· Assignment does NOT mean ownership

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

IPv6 Protocol

Addressing Architecture



Neighbor Discovery

Address Auto Configuration

Aggregatable Addresses





TLA/NLA Assignment Rules

Testing Address Allocation

Multicast Assignments

Path MTU Discovery

Packet Tunneling

V. Mobile IP / Johnson

Status of IPv6 Mobile work.
· Current spec is <draft-ietf-mobileip-ipv6-03.txt>.
· High Level Overview

· One implementation almost available.

Dynamic Home Agent Address Discovery
· Mobile node may not always know its home agent address

· In Mobile IPv4, this is solved by

· 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

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

· Problem: Binding updates MUST be applied ONLY in order

Solution for Binding Updates
· Use IPsec for "Replay Protection"

· Use our own sequence number for sequencing

Getting through Ingress Filtering
· Original Mobile IPv6 addressing for packets sent from a mobile node

· New solution uses "Home Address" destination 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

· At the Receiver

· Implementation of this would be required in all IPv6 receivers

Home Address Option vs. Binding Update Option
· Binding Update option

· Home Address option

Home Address Option Security
· If IPv6 header "source address" is authenticated

· Otherwise

Movement Detection Timing
· Helpful to know when to expect packets from router

· Neighbor discovery provides good source of packet form router

Comments Please
· Send comments to mobile IP mailing list <mobile-ip@smallworks.com>
· Also can be sent to Dave Johnson <dbj@cs.cmu.edu> and Charlie Perkins <cperkins@eng.sun.com>

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

Current Approach
· "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

· 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 gja@lucent.com

VII. IPv6 Transmission over Frame Relay / Conta

Draft: <draft-conta-ipv6-trans-fr-00.txt>

· 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

Draft: <draft-conta-ipv6-trans-tunnel-00.txt>

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

· Mask the forth and fifth octets of the EUI-64 identifier with the fixed 0xFFFC value

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 <aconta@lucent.com>.

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 <aconta@lucent.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]

Name Lookups
· 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)

Address Lookups
· 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

Open Issues
· Node on link can be use this to spoof the address and names returned by the DNS.

· 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

Three drafts:
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

Attendees List

go to list

Previous PageNext Page