NOTE: This charter is a snapshot of the 41st IETF Meeting in Los Angeles, California. It may now be out-of-date. Last Modified: 12-Feb-98
Chair(s):
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:
Done |
|
Submit preliminary IPng core specifications, with required enhancements, as Internet-Drafts. |
Done |
|
Submit revised core IPng specifications as Internet-Drafts. |
Done |
|
Submit core IPng specifications to IESG for consideration as Proposed Standards. |
Done |
|
Submit extended IPng specifications as Internet-Drafts. |
Done |
|
Submit extended IPng specifications to IESG for consideration as Proposed Standards. |
Done |
|
Submit revised specifications to IESG based on implementation experience for consideration as Draft Standards. |
Done |
|
Submit revised IPng specifications as Internet-Drafts. |
Done |
|
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. |
Internet-Drafts:
· Generic Packet Tunneling in IPv6 Specification
· IP Header Compression
· 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
· IP Version 6 Addressing Architecture
· 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
· Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification
· DNS Extensions to support IP version 6
· Basic Socket Interface Extensions for IPv6
· Reverse Address lookup in DNS for IPng.
· Forcing Fragmentation to Network MTU
· Multicast Listener Discovery (MLD) for IPv6
· DNS Lookups Keyed on IPv6 Addresses
Request For Comments:
RFC |
Status |
Title |
RFC1886 |
PS |
DNS Extensions to support IP version 6 |
RFC1885 |
PS |
Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) |
RFC1884 |
PS |
IP Version 6 Addressing Architecture |
RFC1887 |
An Architecture for IPv6 Unicast Address Allocation | |
RFC1897 |
E |
IPv6 Testing Address Allocation |
RFC1981 |
PS |
Path MTU Discovery for IP version 6 |
RFC1970 |
PS |
Neighbor Discovery for IP Version 6 (IPv6) |
RFC1972 |
PS |
A Method for the Transmission of IPv6 Packets over Ethernet Networks |
RFC1888 |
E |
OSI NSAPs and IPv6 |
RFC2019 |
PS |
Transmission of IPv6 Packets Over FDDI |
RFC2023 |
PS |
IP Version 6 over PPP |
RFC2073 |
PS |
An IPv6 Provider-Based Unicast Address Format |
RFC2133 |
Basic Socket Interface Extensions for IPv6 | |
RFC2147 |
PS |
TCP and UDP over IPv6 Jumbograms |
RFC2292 |
Advanced Sockets API for IPv6 |
Minutes of the IPNG (inpgwg) Working Group
Co-Chairs:
Robert Hinden / Nokia
Steve Deering / Cisco
Steve Deering introduced the meeting. Three meeting slots are scheduled. Robert Hinden took and edited the minutes.
The agenda was reviewed. The resulting agenda was:
Monday
Introduction / S. Deering (5 min)
Review Agenda / S. Deering (5 min)
UNH Interoperability Testing / B. Lenharth (5 min)
Document Status / R. Hinden (15 min)
Mobile IPv6 Status / D. Johnson (15 min)
Proposed ND Split / M. Wasserman (5 min)
IPv6 over PVC ATM / S. Deering (10 min)
IPv6 over NBMA & IPv6 over ATM Status / P. Schulter (10 min)
Router Renumbering / M. Crawford (15 min)
Scope Issues / S. Deering (30 min)
Tuesday
Multicast Listener Discovery Protocol / S. Deering (30 min)
IPv6 Plug and Play, Done? / R. Hinden (30 min)
Thursday
DNS Status / S. Deering (30 min)
ICMP Name Lookups / M. Crawford (5 min)
ICMP Node Info / A. Durand (10 min)
Reverse DNS Lookup / M. Crawford (15 min) <draft-ietf-ipngwg-dns-lookups-00.txt>
IPv6 Host Naming Translations / J. Paugh (10 min)
Address Allocation Status Report / R. Hinden (5 min)
I. UNH Interoperability Testing / B. Lenharth
[Editors note: B. Lenharth was not able to give the report. R. Hinden gave summary]
Most recent test event was at Connectheon. No router vendors present. Used Sun as router between two segments.
IMAG BGP4+athon
Five implementations
- cisco
- Digital
- Telebit-DK
- Gated
- MRT
eBGP & iBGP tests
route redistribution
- BGP -> RIP
- RIP -> BGP
II. Document Status / R. Hinden
RFC Published
- RFC 2292 Advanced Sockets API for IPv6 (Informational)
IESG Approved
- MIB for IPv6: Textual Conventions & General_Group / Jun 97 (PS)
- MIB for IPv6: ICMPv6 Group / Jun 97 (PS)
- IPv6 over PPP / Nov 97 (PS)
- IPv6 Testing Address Allocation / Nov 97 (Informational)
- IPv6 Multicast Address Assignments / Nov 97 (Informational)
- IPv6 Packets over Token Ring Networks / Nov 97 (PS)
- Generic Packet Tunneling in IPv6 Specification / Dec 96 (PS)
- IPv6 Packets over FDDI Networks / Nov 97 (PS)
- IPv6 Packets over Ethernet Networks / Nov 97 (PS)
IETF Last Call completed for Proposed Standard
- An IPv6 Aggregatable Global Unicast Address Format / Nov 97 (comments from Registries, new draft)
- IP Version 6 Addressing Architecture / Nov 97 (new draft)
- IP Header Compression / Nov 97 (need new ID, IPSEC)
- MIB for IPv6: TCP / Jun 97
- MIB for IPv6: UDP / Jun 97
Submitted to IESG for Draft Standard
- IPv6 Specification / Mar 98
- ICMPv6 / Mar 98
- Path MTU Discovery for IPv6 / Mar 98
- Submitted to IESG for Proposed Standard
- IPv6 Router Alert Option (IESG returned, need new ID)
Submitted to IESG for BCP
- TLA and NLA Assignment Rules / Nov 97
IPng Working Group Last Call Completed for Draft Standard
- Neighbor Discovery for IP Version 6 (IPv6)
- IPv6 Stateless Address Autoconfiguration
- IPng Working Group Last Call Completed for Proposed Standard
- IPv6 over Point-to-Point ATM Link
- IPng Working Group Last Call Completed for Experimental
- IPv6 Name Lookups Through ICMP
- IPng Working Group Last Call Ongoing
- Router Renumbering for IPv6 (31 Mar 98)
Submitted to IESG
- IPv6 Specification
- ICMPv6
- Path MTU Discovery for IPv6
- Implementation Reports ftp://playground.sun.com/pub/ipng/implementation-reports/
W.G. Last Call Completed
- Neighbor Discovery for IP Version 6 (IPv6)
- IPv6 Stateless Address Autoconfiguration
TLA/NLA Assignment Rules Status
- Plan to Create W.G. Unsuccessful
- Should this be an IETF Document?
- Meeting w/ Registries and IANA Tuesday
- Proposed Changes (consistent w/ Current Aggregation Draft)
- Focus on providing input from wg. to IANA & Registries
- TLA Assignment to all transit providers
- Relax rules for peering and TLA routing
- Remove Auction
III. Mobile IPv6 Status / D. Johnson
Mobile IPv6: IPv6 Changes and Open Issues
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
- Mobile IPv6 uses Home-Agents anycast address for this:
- Mobile node sends to anycast address instead of directly to unicast home agent address
- This home agent replies giving its own unicast address
- But this anycast address (alone) only gets us only one home agent address
- What if we then try to register with it but it says "busy," but there are other home agents on the home subnet?
Improved Home Agent Discovery
- Each home agent keeps a list of other home agents on subnet:
- Home agents set new Home Agent (H) bit in Router Advertisements
- Each home agent keeps a Home Agents List conceptual data structure, similar to Default Router List
- Home agent replies to anycast giving complete list
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cur Hop Limit |M|O|H| Reserved| Router Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reachable Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Retrans Timer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
Other Neighbor Discovery Changes
- New Advertisement Interval option for Router Advertisements:
- Gives MaxRtrAdvInterval so mobile nodes know when they've missed (one or more) Advertisements from it
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertisement Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Discussion about need for this. Comparison with special home agent protocol. Mobile nodes need easy way to learn that they have moved. Proposal for sending to anycast address of home agent. Possible any assignment of "3" (0 is subnet router, 1 & 2 are for point-point link address assignment, 3 is next).
Discussion about can interval be less than one seconds. Should ND be change to use milliseconds instead of seconds? Why is less than once second needed?
Question about do all links need high frequency beacons? Only wireless? Mobile IP is not focused on wireless only.
- Also allow MinRtrAdvInterval for home agents < 3 seconds:
- Frequently enough to ``learn of their presence within a few minutes'' is not fast enough for mobile nodes moving about
- Routers wanting to provide good service to mobile nodes MAY advertise more frequently
Other Issues for IPng Working Group
- How do we satisfy our IANA Considerations?
- Need Destination Option type codes for 4 options
- Need an anycast address for Home-Agents anycast
- How do people know about Mobile IP SHOULDs and MUSTs?
- Most important is requirement to be able to process received Home Address option - This applies to all implementations: hosts and routers, mobile and stationary --- everybody!
- Suggestion: For now, collect all IPv6 requirements on a Web page, advertise it widely
- Really need to write a real ``requirements'' document, but that's a big job (and too slow)
ACTION DOC EDITOR: Get assignment for these options code points and start the anycast address assignment. Collect all code points. ND, ION, mobileIP etc.
Deering and Johnson will write short draft describing anycast assignment in the next two weeks.
Comments, Please
- We are very close to going to Last Call for Mobile IPv6
- We need feedback/agreement from IPng Working Group
- Please send e-mail comments to the Mobile IP mailing list: mobile-ip@SmallWorks.COM
- Comments can also be sent to:
- Dave Johnson, dbj@cs.cmu.edu
- Charlie Perkins, cperkins@eng.sun.com
IV. Proposed ND Split / M. Wasserman
ND is a useful set of mechanisms. Many IPv6 host will (and should) implement the full set. Some ND mechanisms may not apply to some:
- link types
- node types
- situations
Proposal to split ND into eight separable ND mechanisms
- Address Resolution
- Duplicate Address Detection (DAD)
- Router Discovery
- Prefix/parameter Discovery
- Address Autoconfiguration
- Router Unreachability Detection
- Neighbor Unreachability Detection (NUD)
- ICMP Redirects
Requirement for minimal IPv6 functionality on many link types:
- Address Resolution
- DAD
- ICMPv6 redirects
Advanced Features:
- Configuration
- Router Discovery
- Prefix/Parameter Discovery
- Address Autoconfiguration
- "Blackhole" detection / Fall back
- Router Unreachability Detection
- NUD
Configuration "scopes":
- Per link-type: all nodes must implement for communication to occur
- Address resolution
- ICMPv6 Redirects
- Per link: Usefulness depends on cooperation of all nodes on link:
- Duplicate address detection
- Per link: Usefulness depends on cooperation of all routers on link:
- Router discovery
- Prefix/Parameter discovery
- Per host/per-interface: can be useful without cooperation of all hosts on link:
- Address Autoconfiguration
- Router/Neighbor Unreachability detection
Suggested specification changes
- Make distinction between 8 mechanisms
- Assign configuration scope, recommendations and defaults
- Describe for separate implementations
Suggested specification split:
- Put minimal required mechanisms, related messages and descriptions into separate document
- Address resolution
- DAD
- ICMPv6 Redirects
Discussion. Suggestion was made that this document can define what is appropriate for each link types and what can be turned off. It would be an applicability document for ND and Autoconfiguration.
V. IPv6 over PVC ATM / S. Deering
Two competing specs for how to run IPv6 over ATM in a PVC mode. Point-to-point links between IPv6 nodes as opposed to using ATM in NBMA mode.
IPv6 over PVC ATM draft and ION NBMA draft. In previous meetings the approach discussed was that there would be a separate document that defined this mode independently from full NBMA draft. Deadline proposed. Chairs believe deadline was end of January 1998 and that deadline has passed. ION document were published prior to March 1998 meeting.
In ION documents IPv6overPVC-ATM is not in one place but spread over many sections in two documents. Some differences in two approaches: MTU, generation of link-local addresses, others?
Deering's personal opinion is that it should not be spread over two documents. Would prefer PVC case to be in a single document.
Stopped discussion and did following ION status.
VI. IPv6 over NBMA & IPv6 over ATM Status / P. Schulter
ION meet today and discussed this issue.
<draft-ietf-ion-ipv6-01.txt>
Grenville Armitage (Lucent)
Peter Schulter (Bright Tiger Technologies)
Markus Jork, Geraldine Harter (Digital)
The General Architecture
- Assume general NBMA 'cloud'
- Capable of pt-pt links (static or dynamic)
- Capable of pt-mpt links (dynamic, real or emulated)
- May or may not have native 'multicast'
- NBMA cloud could be
- ATM
- Frame Relay
- IPv4 network
- MARS ? NHRP ?
- Only used for SVC mode where native multicast is not supported, and dynamic shortcuts make sense
Since last we met....
- Modified host triggered redirection behavior (replies are now Redirects)
- Added new Shortcut Limit option for host triggered redirect (NS) message
- General text cleanup
Open Issues:
- Assignment of a new ND option number (we picked the next available number)
ACTION IPng Doc Editor: Get option assignment
<draft-ietf-ion-ipv6-atm-01.txt>
- What is it?
- <draft-ietf-ion-ipv6-atm-01.txt> is a media-specific companion document to <draft-ietf-ion-ipv6-01.txt>
- Contains
- Rules of generation of ND link tokens and link address fields
- Codepoints for MARS and NHRP messages
- Rules for LLC/SNAP encapsulation
- Null encapsulation optional
- Covers PVC and SVC cases separately
- Clients do not need to implement SVC related extensions (e.g. MARS) if only PVC support is required
PVC rules
- Standard LLC/SNAP encaps, with IPv6 PID
- Null encapsulation allowed/negotiable
- Default IP MTU of 9180 octets
- All PVC rules now in section 3.1 (encapsulation, MTU, link token generation)
SVC rules
- Standard LLC/SNAP encaps with IPv6 PID
- Different unicast and multicast formats as per RFC2022
- Null encapsulation discouraged, since it cannot be used between MARS and IPv6/NBMA client anyway
VII. Continuation of IPv6 over PVC ATM Discussion / S. Deering
Three points:
1) Technical differences. "IPv6 over Point-to-Point ATM Link" <draft-yamamoto-ipv6-over-p2p-atm-01.txt> spec is what has been implemented in WIDE implementation.
2) Should there be a stand alone document?
3) If we go with ION document, there should be proper acknowledgment of <<draft-yamamoto-ipv6-over-p2p-atm-01.txt> authors.
Asked for comments. discussion. Many liked separate document. Suggested to use ION link-local rules. Another comment suggested that once technical issues resolved we should go with ION work. Suggestion that ION has been implemented as well. Discussion should have happened in ION.
K. Yamamoto is willing to defer to ION, but wants it out quickly. Deering suggested that K. Yamamoto and ION authors get together and resolved differences. Would still like to have the PVC document be stand alone.
Will go forward with ION document with closer coordination from K. Yamamoto.
VIII. Router Renumbering / M. Crawford
Status draft -03
- In wg. last call
- Outstanding issues
- Stagger replies to multicast command
- Limit multicast destination addresses to all routers only
- Check for formation of unacceptable address (multicast, etc.) during execution
- Open questions
- enable matching conditions on length of prefix? Yes
- Forbid formation of v4-compatible address? Yes
- Discard custom authentication -IPSEC only? Yes, frees up field
Spin-Off work
- Define "Site"
- Or agree not to
Comment that given authentication this document does not need to definesite. Security implicitly defines site.
VIII. Multicast Listener Discovery Protocol / S. Deering
New draft out <draft-ietf-ipngwg-mld-00.txt>. Equivalent of IPv4 IGMP for IPv6.
Changes:
- Using Link-local address for sourcing messages
- Packet formats
- Terminology
Solicited comments.
IX. Scope Issues / S. Deering
Discussion with diagrams.
| | |
| | |
| | |
+--------+ +--------+ +--------+
| | | | | |
| Rtr | | Rtr | | Rtr |
| | | | | |
+--------+ +--------+ +--------+
| | |
| | |
| | |
============================================
Link Local: Drew scope boundary through the middle of Routers
Site Local: Showed three alternatives. First site boundaries is in the middle of routers. Second boundary is in the middle of links. Third is interface based.
Assumption that sites are not overlapping. Overlapping sites are not currently supported. There is only one site-local prefix.
Question about why we want site local. Why do we want to have them? This was discussed at length on mailing list. Conclusion was to keep them. It would be more destructive to get rid of them, than to keep them and to define usage. Current objective is they are useful during renumbering. Site local addresses don't have to change.
Comment that Erik Nordmarks draft is only defined usage of site-local. Think we can keep this usage without defining in detail.
Deering want to propose simple definition with guidance for implementors. If they don't get use, this will not be a problem.
+--------+ +--------+
| | | |
| Rtr 1 +--------------------+ Rtr 2 |
| | | |
+--------+ +--------+
..site A.. | ..........site B........... | ......site C.........
In this example there is a site boundary between each router. This
results in three sites (left 1/2 of rtr 1, right 1/2 of rtr 1 through
left 1/2 of Rtr 2, etc.
Long discussion.
General consensus in the discussion to keep site local and agreement to make site boundaries in node (not link or interface).
ACTION: S. Deering to write a draft
X. IPv6 Plug and Play, Done? / R. Hinden
Context
- Plug and Play likely to be IPv6's Carrot
- Makes IP Easy to Use!
- Lowers Cost of Ownership for Enterprises and ISP's
- Enables Network Appliances
- Phones, PDAs, Games, household appliances, etc.
Where Are We Now?
- ND and AddrConf
- Global Address Creation
- Router Discovery
- IP Parameters
- DHCPv6
- Router Renumbering
- Centralized reconfiguration of Router Advertisement Information
- DNS
- Automatic Creation of Reverse Map
What Is Missing?
- DNS
- How to find DNS Server
- How to register Node DNS name
- Services
- How to find Printers, File Servers, etc.
- Enterprise and Home Office solution
Solutions
- Role of Service Location Protocol
- Appropriate for General Service Location
- Works with and without Servers
- Not appropriate for DNS server location
- DNS Server Location
- Need Something New
- DNS Name Registration
- Status of Dynamic DNS Updating?
DNS Server Location
- Need to Learn
- Server Address(s)
- Default Domain
- Domain Suffix Search list
- Others?
- Issues
- Authentication
- Lifetimes
- Changing
Approaches
- Add Attribute to ND Router Advertisements
- Requires adding this info to Routers
- What if no Router?
- DNS Server Advertisements?
- Anycast Address for DNS Servers
- Requires further communication w/ DNS server to get other related information
- Multicast Address for DNS Servers
- Use Expanding Ring (TTL) Search
Next Steps
- Discussion
- Pick Approach
Ohta: for DNS lookups, and DNS server will do; for registering/updating names, need specific server
Nordmark: what about coffee machines without keypads?
Bound: don't dump on servers!
Cheshire: svrloc allows literal addresses, so would work fine for DNS discovery
Deering: maybe spin off to a separate working group?
Bound: to use anycast, need to allow hosts to have anycast addrs
Durand: DNS service itself is complex, server-based; not exactly what dentists want?
More random discussion.
General conclusion that topic should be pursued, but not clear if it should be in the IPng working group.
XI. DNS Status / S. Deering
First item is where we are in DNS work. Major piece of core charter. Need to find current state and what should we do. What document should be moved forward, what not, what else needs to be done. Solicited opinion.
CH: Did revision of draft based on previous decision. Submitted first release in January. New draft based on comments. Draft stable. Added tutorial part, comment to expand this and clarify. Reluctant to do any changes. Wants doc to go to wg. last call. Has not received any major objections. Only wants to make changes based on wg. comments. Waiting for results of reverse lookup.
Publish as is or merge with new reverse lookup approach. Relationship w/ current RFC. Backwards compatible with current AAAA RFC. Conclusion (w/ no objections) is this will replace current AAAA RFC. RFC1886 will become obsoleted (historic).
ACTION: Chairs do W.G. last call for when new draft is out.
XII. ICMP Name Lookups / M. Crawford
Status (-02)
- In wg. last call for experimental.
- Could rolled in with several other suggestions. Wants to hold off moving this forward until that is resolved.
XIII. ICMP Node Info / A. Durand
ICMP Node Info / Local extensions of ICMP "who are you"
Motivation
- Local address <=> "local name" mapping
- Local address <=> global address mapping
- local topology discovery
- "local name" space discovery
_ local means "link local" or "site local"
- Something very simple
Two ICMP types, several codes, X: request, Y: reply
X/0: "localname" request Y/0: "local name" reply
X/1: incoming interface Y/1: incoming interface
global address request global address reply
X/2: all interfaces global Y/2: All interfaces global
address request address reply
Unicast Usage
- X has only Y link local address and wants to discovery:
- Y "local" name
- Y global addresses
Multicast Discovery
- "Allowed" multicast destination addresses
- All node link local
- All router link local
- All route site local
- Source address of requests and replies packets MUST be local
- Replies may be multicast to all node link local
- anti-flooding mechanisms are needed
Security Considerations
- Do we open a can of worms?
- Is IPSEC appropriate
- If yes, is it necessary?
Question: relationship between this and link local naming.
CH: Should coffee pot use this or DNS? Answer this. Discussion. Generally thinks naming functions should be in DNS resolver and not in ICMP.
M. Otha: Should this be used in sites? No only link scope. These names should only be used with limited scope. This can be used to discover all of the names on the link.
Deering: Thinks functionality should be in resolver, but that doesn't mean that this needs to be in DNS protocol. Matt: Could make small changes to "who are you" draft to allow more request types and replies.
Kazu: Doesn't link this under ICMP. On Unix systems UDP would be better. Need root access to send/receive ICMP messages.
ACTION: Chairs to figure out how to keep this work going. Might be in new wg., somewhere else.
Dimitry H: Need mechanisms to discover global address of router from link-local address. Doesn't think SNMP is appropriate. Could add ND option to router advertisement to advertise global address of router. Can we require routers to accept packets sent to prefix it is advertising with interface ID from link local address of router. Becomes an anycast address for router.
Deering: links and subnets are not necessarily the same thing. Would like architecture to allow subnets to span multiple links.
Discussion:
Nordmark: Wants to keep node in control of what addresses it uses.
Doesn't want other nodes to decide. Also, is this also needed for hosts
too?
Bound: Thinks we should just have ND advertise all address of node.
Nordmark: If so, would need to add lifetimes with each addresses. Lots
of detail here.
Otha: Thinks sites are collection of links.
Discussion....
XIV Reverse DNS Lookup / M. Crawford <draft-ietf-ipngwg-dns-lookups-00.txt>
IPv6 DNS Lookups
Goals and Semi-Goals
- Delegate on arbitrary boundaries
- Cacheable intermediate data
- A single zone can be used under multiple higher-level prefixes.
- Zone needs no modification if net is renumbered
- Coexists with existing ipv6.int
- Forward and reverse can be in sme zone file.
New DNS Tools
- Binary Labels
- Compact representation of bit-string with semantics of a sequence of 1-bit domain labels: \[x200100/24].ip6.int.
- Longest-match fallback when name or data not found
- Non-terminal domain renaming (DNAME)
- Maps a suffix set of labels to a different suffix: c.d.d.f. DNAME y.z causes a query for a.b.c.d.e.f. to go to a.b.y.z
Proposed Structure
- Higher-level registries of ISPs delegate address space to a domain chosen by the lower-level entity.
- The delegated prefix disappears in the mapping
- Hence, lower-level domain can be used with multiple prefixes
- The delegating DNAME record can be cached
[ Slide w/ examples]
Pesky Details
- How to look up site-local addresses?
- Resolvers know to use only same-site DNS server?
- Top level delegates \[xFEC0/10] to special name with site-local addresses?
- Like <draft-ietf-dnsind-local-names>
Questions: Has this been reviewed by DNS wg? Meet yesterday, feeling is that it should be done. Some technical details to work out, but should be done quickly. Expect to be done by next IETF meeting (August 98).
CH: Thinks this is compatible with new DNS draft. Has talked to Matt C. about it. Good to have all of this together. Good thinking, very complementary. All data in one place. Only practical question is of timing. Relationship between DNAME and Binary Labels? Could this be blocked for a long time? Matt did not think this would happen. KRE: DNS group has a good track record to get work out. Should be ready for IESG by next IETF.
Conclusion is to merge the two drafts.
XV. IPv6 Host Naming Translations / J. Paugh
Solaris NIS/NIS+ Naming Services
Goal is to not break IPv4 applications
IPv4 & IPv6 Addresses Stored Separately
- NIS map, NIS+ table and /etc file created for IPv6 addresses
- Prevents existing IPv4 applications from unexpectedly receiving IPv6 addresses
- Separate IPv6 database can be served by older slave/replica
Server Side Changes
- New IPv6 host database created
- hosts6.byname/hosts6.byaddr maps for NIS
- hosts6.org_dir table for NIS+
- "AAAA" record for DNS
- /etc/inet/hosts6 file for local file
- Updated utilities to create hosts6 database (ypmake(1M), nisaddent(1M), nispopulate(1M), etc)
[ Figure showing getXbyY() Application ]
XVI. Address Allocation Status Report / R. Hinden
Meet with registries and IANA. General conclusion is continue with approach described on Monday. New change is approach to initially assign sub TLA to transit providers who request allocation. When this is 90% used, they can then ask for a full TLA. This will be assigned with the understanding that they will have to give back the sub-TLA after a transition period. This should keep the top level routing in the order of the number of transit providers. Will work with registries and IANA to revise the draft. Expect to publish it in early May.
Dimitry: Make sure policy doc does not rule out allocation of TLAs to exchanges.
Carpenter: this doc will not be an IESG-approved doc; will be published as Informational RFC.
XVII. IANA Status / R. Hinden
Meet with Jon Postel. Will collect and sanitize current code point request and send to IANA. Future request sent to IANA will be reviewed by IPng document editor.
R. Hinden will serve as IANA technical reviewer for v6 numbers; asked for all spec authors to email him their code-point requirements and corresponding document citations.
Meeting adjourned.
None Received