NOTE: This charter is a snapshot of the 43rd IETF Meeting in Orlando, Florida. It may now be out-of-date. Last Modified: 25-Nov-98
Chair(s):
Bob Hinden <hinden@iprg.nokia.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
· A Method for the Transmission of IPv6 Packets over ARCnet Networks.
· Transmission of IPv6 over IPv4 Domains without Explicit Tunnels
· Management Information Base for IP Version 6: Textual Conventions and General Group
· Management Information Base for IP Version 6: ICMPv6 Group
· Transmission of IPv6 Packets over FDDI Networks
· Transmission of IPv6 Packets over Ethernet Networks
· Separating Identifiers and Locators in Addresses: An Analysis of the GSE Proposal for IPv6
· 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
· Proposed 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 Extensions to Support IP Version 6
· The IPv6 Jumbo Payload Option
· Reserved IPv6 Subnet Anycast Addresses
· Routing of Scoped Addresses in the Internet Protocol Version 6 (IPv6)
Request For Comments:
RFC |
Status |
Title |
RFC1885 |
PS |
Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) |
RFC1886 |
PS |
DNS Extensions to support IP version 6 |
RFC1887 |
An Architecture for IPv6 Unicast Address Allocation | |
RFC1883 |
PS |
Internet Protocol, Version 6 (IPv6) Specification |
RFC1897 |
E |
IPv6 Testing Address Allocation |
RFC1981 |
PS |
Path MTU Discovery for IP version 6 |
RFC1888 |
E |
OSI NSAPs and IPv6 |
RFC1972 |
PS |
A Method for the Transmission of IPv6 Packets over Ethernet Networks |
RFC1970 |
PS |
Neighbor Discovery for IP Version 6 (IPv6) |
RFC2019 |
PS |
Transmission of IPv6 Packets Over FDDI |
RFC2023 |
PS |
IP Version 6 over PPP |
RFC2133 |
Basic Socket Interface Extensions for IPv6 | |
RFC2147 |
PS |
TCP and UDP over IPv6 Jumbograms |
RFC2292 |
Advanced Sockets API for IPv6 | |
RFC2373 |
PS |
IP Version 6 Addressing Architecture |
RFC2374 |
PS |
An IPv6 Aggregatable Global Unicast Address Format |
RFC2375 |
IPv6 Multicast Address Assignments |
IPng Working Group
December IETF
Bob Hinden / Nokia
Steve Deering / Cisco
Co-Chairs
Steve Deering introduced the meeting. Two meeting slots were scheduled.
Bob Hinden took and edited the minutes.
Thursday 3:30PM - 5:30PM
Friday 9:00AM - 11:30AM
The agenda was reviewed. The resulting agenda was:
Agenda:
- Introduction / S. Deering
- Review Agenda / S. Deering
- Unified IPv6/IPsec Stack / K. Kamamoto
- Document Status / R. Hinden
- IPv6 Code Points / R. Hinden
- IPv6 6REN Status and Plans / R. Fink
- Addressing to Draft Standard / R. Hinden
- Initial IANA Sub-TLA Assignments / R. Hinden
- IPv6 over IPv4 w/out Explicit Tunnels / B. Carpenter
- Basic API Revision / J. Bound
- DNS Extension to Support IP Version 6 / M. Crawford
- Reserved IPv6 Subnet Anycast Addresses / D. Johnson, S. Deering
- Jumbograms / S. Deering
- Router Renumbering / M. Crawford
- Multicast Listener Discovery Protocol / S. Deering
- Separating Identifiers and Locators in Addresses: An Analysis of the GSE
- Proposal for IPv6 / L. Zhang, et. al.
- Site Prefixes in Neighbor Discovery / E. Nordmark
- Future IPv6 Direction / S. Deering
- Mobile IPv6 Status / D. Johnson
- IPv6 TCP and anycast address / Jun-ichiro Itoh
- RPC and NFS over IPv6 / L. Wu
- Tunnel Broker / A. Durand
Unified IPv6/IPsec Stack / K. Kamamoto
We decided to merge our code:
- INRIA
- NRL
- Kame Project
- to provide a single free reference code
Targets are BSD variants
- FreeBSD
- NetBSD
- OpenBSD
- BSD/OS
Schedule
- Hopefully by next summer
Document Status / R. Hinden
RFC Published
- RFC2460 Internet Protocol, Version 6 Specification (DS)
- RFC2463 ICMPv6 (DS)
- RFC2461 Neighbor Discovery for IP Version 6 (IPv6) (DS)
- RFC2462 IPv6 Stateless Address Autoconfiguration (DS)
- RFC2454 MIB for IPv6: UDP (PS)
- RFC2452 MIB for IPv6: TCP (PS)
- RFC2465 MIB for IPv6: Textual Conventions & General Group (PS)
- RFC2466 MIB for IPv6: ICMPv6 Group (PS)
- RFC2472 IPv6 over PPP (PS)
- RFC2471 IPv6 Testing Address Allocation (Experimental)
- RFC2470 IPv6 Packets over Token Ring Networks (PS)
- RFC2467 IPv6 Packets over FDDI Networks (PS)
- RFC2464 IPv6 Packets over Ethernet Networks (PS)
- RFC2450 Proposed TLA and NLA Assignment Rules (I)
- RFC2473 Generic Packet Tunneling in IPv6 Specification (PS)
IETF Last Call completed for Proposed Standard
- IP Header Compression / Nov 97
- Waiting for new draft
- IPv6 over ARCnet Networks
- Waiting for new draft
- Router Renumbering for IPv6
- IESG Comments
Submitted to IESG for Proposed Standard
- IPv6 Router Alert Option
- IESG wants to reconcile w/ IPv4 Router Alert
- Reserved IPv6 Subnet Anycast Addresses
- DNS Extensions to Support IP Version 6
IPng Working Group Last Call Completed for Proposed Standard
- IPv6 Jumbo Payload Option
- Transmission of IPv6 over IPv4 Domains without Explicit Tunnels
IPng Working Group Last Call Completed for Informational
- Basic Socket Interface Extensions for IPv6
- Waiting for new draft
- Initial IPv6 Sub-TLA ID Assignments
IPng Working Group Last Call Completed for Experimental
- IPv6 Name Lookups Through ICMP
IPv6 Code Points / R. Hinden
Assignments for:
- ICMPv6 Parameters
- IP Version 6 Parameters
Accepted by IANA
Available on IANA Assigned Numbers Web Site: http://www.iana.org/numbers.html
Carpenter: Important to carefully document IANA<->WG procedures for parameter assignment. Best to do as an RFC with big stamp of approval from the IESG.
Addressing to Draft Standard / R. Hinden
Addressing Documents
- RFC2373 IPv6 Addressing Architecture
- RFC2374 An Aggregatable Global Unicast Address Format
Implementation reports available at: ftp://playground.sun.com/pub/ipng/implementation-reports/
- file name:
- add-arch-aggregat.txt
- Additional reports desirable
Start working group last call for Draft Standard
Implementation reports available. Bob proposes to start last call at this point for advancement of these 2 documents to Draft Standard. No objections.
ACTION: Document editor will start working group last call to move the IPv6 addressing specifications to Draft Standard.
Initial IANA Sub-TLA Assignments / R. Hinden
Regional IP Registries plan to start allocating IPv6 addresses in Q1 1999
- Responding to requests from ISPs planning production IPv6 service
RIRs each need initial blocks of Sub-TLA ID's to assign
New draft to propose initial Sub-TLA ID Blocks: "Initial IPv6 Sub-TLA ID Assignments"
<draft-ietf-ipngwg-iana-tla-00.txt>
Background
| 3 | 13 | 13 | 19 | 16 | 64 |
+----+------+-------+---------+------+--------------------------+
| FP | TLA |Sub-TLA| NLA | SLA | Interface ID |
| | ID |ID | ID | ID | |
+----+------+-------+---------+------+--------------------------+
^
|
|
FP = 001 = Format Prefix
TLA ID = 0x0001 = Top-Level Aggregation Identifier
Sub-TLA ID Assignments
Binary Range (Hex) Assignment
---------------- --------------- -------------------
0 0000 00XX XXXX 0x0000 - 0x003F IANA
0 0000 01XX XXXX 0x0040 - 0x007F APNIC
0 0000 10XX XXXX 0x0080 - 0x00BF ARIN
0 0000 11XX XXXX 0x00C0 - 0x00FF RIPE NCC
0 0001 00XX XXXX 0x0100 - 0x013F (future assignment)
0 0001 01XX XXXX 0x0140 - 0x017F (future assignment)
0 0001 10XX XXXX 0x0180 - 0x01BF (future assignment)
0 0001 11XX XXXX 0x01C0 - 0x01FF (future assignment)
0 0010 00XX XXXX 0x0200 - 0x023F (future assignment)
. . .
. . .
. . .
1 1111 11XX XXXX 0x1FC0 - 0x1FFF (future assignment)
Where "X" indicates "0" or "1".
Carpenter: Tuesday night, the IAB sent a request to IANA to assign blocks of sub-tla's to APNIC, ARIN, and RIPE-NCC in the same manner as specified in the draft.
IPv6 6REN Status and Plans / R. Fink
IPv6 Research and Education Networks Initiative
The problem
- Given the several years it will take to integrate existing implementations of IPv6 into production release products
- and the several years it will take to work out all the details of making Internet applications work transparently over IPv6
- what do we do during this interval to maintain momentum for IPv6...?
Where we are
- We have standards, we have lots of implementations... we now need deployment
- The R&E network community can now contribute substantially to IPv6, in the way it did to establish the Internet, ...
- by creating production IPv6 networks suitable for real applications to use
A start
- In early October, ESnet established native IPv6 over ATM peering with CAIRN, Internet2/vBNS and CA*net2
- In December, with WIDE
- and established an open participation initiative, the 6REN, to act as a rallying point for all RENs world-wide to provide production IPv6 service
Isn't this just the 6bone?
- The 6bone is a testbed network, operated under a testbed AUP, and is not operationally robust due to this fact
- The 6ren is going to promote and coordinate production quality IPv6 service
- The 6ren is NOT a network
6REN participation
- Free and open to all Research and Education Networks that provide IPv6 service
- Other for-profit and not-for-profit IPv6 networks are also encouraged to participate on this basis as well
- The 6REN is more like a NANOG for IPv6
Work underway
- A planning/formation meeting was held during this IETF Orlando meeting week
- Existing 6bone pTLAs are being approached to find out can participate in this effort
More work
- Working with David Kessens to provide network registry service similar to that provided for the 6bone
- Reverse DNS (ip6.int) registry planned to be provided through ISI, under IANA oversight, as done now for 6bone
- ESnet will provide transit for the 6bone to all 6ren participants (with some proviso) next line
- Convert the early participants to production IPv6 addresses as soon as the registries start handing out Sub-TLAs early next year
- Work on making these networks provide production quality IPv6 service
Also of interest
Effort is underway to help Australia and China RENs to develop plans and proposals to provide country-wide production IPv6 service
- AARNET - the Australian Academic and Research Network
- CERNET - the China Education and Research Network
The Environment Today
- State as of mid-December 1998
+------------+ Direct native IPoverATM
/| Internet 2 | PVC links w/ BGP4+ peering
/ +------------+
/
+-------+ / +------+
| |/ | |
| ESnet |----------------| WIDE |
| |\ | |
+-------+ \ +------+
| \
| \
| \
+-------+ \+-------+
| CA*net| | CAIRN |
+-------+ +-------+
Providing...
- Motivation to run real Internet applications over a native IPv6 infrastructure
- A possible incentive might be using it to provide a "quality" path
- ... and because it's the "right" thing to do :-)
Applications and IPv6
- Remember, no application we know of needs IPv6 to run
- This is a feature, not a "bug"
- This feature is the way we guarantee transitioning from IPv4 to IPv6 is transparent as possible
Join the 6REN Initiative
- See the new web site for the 6REN: http://6ren.net
- Contact Bob Fink <fink@es.net> if you have any questions
Bound: Corporate America doe snot have to wait for Microsoft. There are reasons to deploy now.
IPv6 over IPv4 w/out Explicit Tunnels / B. Carpenter
Working group last call. Draft discussed here and in NGTRANS.
Comments:
Section 7 of document will be removed because it was half baked and draft will be reissued.
ACTION: Document editor to send "IPv6 over IPv4 w/out Explicit Tunnels" to IESG for PS when new draft is out.
Basic API Revision / J. Bound
As soon as new ID is out, DE is submitted for Informational.
ACTION: Document editor to send "Basic API Revision to IESG for informational when new draft is out.
DNS Extension to Support IP Version 6 / Matt Crawford
Document Status
- Chairs requested ADs to advance it on October 15, 1998.
- Depends on two dnsind wg drafts, which that chair passed to ADs Sep 22 & Sep 27.
- One or both of which depend on "EDNS0" draft that just need a an IANA considerations section.
Implementation / Experimentation
- A6, binary labels and DNAME will be in BIND 9.
- Experimental variant of 8.2 may be available sooner.
Deployment Concerns
- What if site is partitioned from the internet for an extended period?
- At least two classes of solutions, including a spectrum of configurations choices in zone.
- Need applicability statement
- Glue records need scrutiny
- ... to see how much of the same protection is appropriate.
- What if your provider or DNS parent makes a mistake?
- Same foot, same gun, new bullet.
Router Renumbering / M. Crawford
Two small sets of IESG comments received
- Editorial and wording preferences
- Request for instructions to implementors and user regarding retransmission strategy.
New draft should resolve IESG issues and allow this to move forward.
Jumbograms / S. Deering
It was reported that we now have two interoperable implementations. Can this move to Draft Standard now? Will this satisfy IESG requirements? It was already at proposed when it was part of IPv6 specification. Internet AD answered that it would be better to start at Proposed Standard.
Comment to combine this with TCP/UDP jumbograms to produce one Jumbogram documents. After some discussion, documents authors will decide appropriate approach.
Multicast Listener Discovery Protocol / S. Deering
A new version of the draft is needed. Also, found problem with behavior when query time of zero. Needs to be defined meaning of zero. Zero will mean zero delay.
Deering will issue new draft.
It was noted that is dependent of IPv6 Router Alert.
Concern raised about attack w/ zero value. Need to make sure these messages can not be forwarded from routers.
ACTION: Document Editor will start w.g. last call for "Multicast Listener
- Discovery Protocol" for Proposed Standard once new ID is published.
Separating Identifiers and Locators in Addresses: An Analysis of the GSE Proposal for IPv6 / L. Zhang, et. al.
History
- Feb '97: IPng interim meeting on GSE proposal
- draft-00 in summer '97, mostly reporting on the meeting discussion and consensus, received lots positive feedback and comments.
- The authors all got overloaded, dragged on the revision for a looooong time period
Current State and Next Step
- draft--3 (this IETF) mostly focus on the analysis of pro's and con's of separating locators and identifiers:
- Overloading address field with both functions has its architectural importance
- The separation introduces new issues that have no clear solutions
- Request WG last call to publish the analysis as an Info RFC.
ACTION: Document editor will issue w.g. last call for publishing
- "Separating Identifiers and Locators in Addresses: An Analysis of the GSE Proposal for IPv6" as an Informational RFC.
Site Prefixes in Neighbor Discovery / E. Nordmark
Site prefixes in Neighbor Discovery <draft-ietf-ipngwg-site-prefixes-02.txt>
Outline
- Site model including mobile nodes
- Proposed protocol
- Mobility issues
Model
- An interface belongs to (at most) one site.
- A link belongs to (at most) one site.
- A node (host or router) can have interfaces in multiple sites.
- Site boundaries pass through nodes - not through links.
Model for mobile nodes away from home
- Always considered to have one interface in its home site.
- This interface is the conceptual tunnel to its home agent and nodes in the home site.
- Implies that mobile nodes are "multi-sited".
Proposal
- Routers advertise "site prefixes" - global address prefixes assigned to the site.
- Nodes use the site prefixes to determine what global addresses are part of the site.
- Site local (and global) addresses stored in the (global) DNS.
- "Resolver" filters out site local addresses unless one or more global addresses match a site prefix.
- Site locals only used when peer is known to be in same site as sender.
Prefix option format
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Prefix Length |L|A|R|S|Resvd1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Valid Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preferred Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Site PLength | Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Prefix +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
S site prefix flag: Site PLength is valid.
Site PLength: Number of bits in site prefix.
Example
- RRset in DNS
2837:a:b:987:X:Y:W:Z1 2000:1:2:987:X:Y:W:Z1
fec0::987:X:Y:W:Z1 2837:a:b:34:X:Y:W:Z2
2000:1:2:34:X:Y:W:Z2 fec0::34:X:Y:W:Z2
2abc:77:66:23:X:Y:W:Z3
- Advertised site prefixes:
2837:a:b::0/48 2000:1:2::0/48
- Addresses used by application:
fec0::987:X:Y:W:Z1 fec0::34:X:Y:W:Z2
- Instead if site prefix list is empty apps use:
2837:a:b:987:X:Y:W:Z1 2000:1:2:987:X:Y:W:Z1
2837:a:b:34:X:Y:W:Z2 2000:1:2:34:X:Y:W:Z2
2abc:77:66:23:X:Y:W:Z3
Question about motivation. Beneficial, if you think internet is not going to renumber, wants to use site local addresses for all internal traffic. Only have external traffic use global addresses. Make internal traffic impervious to renumbering.
Comments:
This is a big deal and makes DNS resolver very complex.
Thinks draft has not been read/understood. Thinks we should do this.
Should we add this to BIND9? Some work in resolver.
Another motivation for this is that site local address are the IPv6 equivalent of "Net10" private address space. Some people think having private addresses are important. This draft helps make this work. llows site to use both private and public with not difficult transition.
Impact of deployment? Can we get all implementations done in timely manner? Requiring two-faced DNS would be a mistake.
Mobile nodes
- Will acquire global care of address(es).
- Might acquire a site-local care of address. (but not useful).
- Retain any site local address from home site.
- Only use this when communicating over the conceptual interface to the home site.
- Detect when moving away from the home site and back.
- Using the advertised site prefixes.
Home agents
- No changes. Proper source address selection when originating packets sufficient.
Correspondent nodes
- When the binding cache for a site local destination has a global care of address:
- Include a Home Agent option containing the site local source address.
- Ensures that the source address of the IPv6 header is a global address when the packet leaves the site.
Summary
- All nodes must start ignoring site local addresses returned from the DNS.
- As site prefixes become advertised these addresses can be used.
Questions/Comments:
This works by matching up something in ND messages w/ what is in DNS.
Could also do DNS-DNS matching. Reply: This wouldn't work for Mobile nodes.
Deering: Some people are unhappy with this.
Any impact on firewalls? No
Question about leakage of internal structure of DNS information outside of network.
How would work w/reverse zones. Answer in draft. Can construct reverse addresses
Jim Bound thinks this will help deployment.
Chair took poll to see if having to make resolver changes to support this is too hard. No strong objection. Strong agreement to continue this work.
Future IPv6 Direction / S. Deering
What should happen next? Lots of this we could do? Or not.
- more auto config, discovery of names, etc.
What chairs had in mind was to hold an interim IPv6 meeting. Tentatively first week of February. Review state of IPv6 protocols and transition mechanisms. Identify new works, new approaches, etc.
Initial proposal to meet at LBNL in S.F. Bay area. First two day would be combined NGTRANS and IPng first two days. Third day would be coordination, 6REN, 6BONE, etc.
Polled room to see who could attend: Many would attend.
Another proposal to have meeting in Europe or Japan. Possible sponsors should talk to Chairs after meeting.
Editor Note: Subsequent to the meeting it has been announced that the Interim meeting will be held on February 2-4 in Grenoble France. Details sent to IPng and NGTRANS mailing lists.
Mobile IPv6 Status / D. Johnson
<draft-ietf-mobileip-ipv6-07.txt>
Completed w.g. last call and has been submitted to IESG. IETF last call should occur soon.
New Encoding for Operational Information
Unique Identifier Sub-Option
Home Agents List Sub-Option
Dynamic Home Agent Address Discovery Details
Comment: This and RR need to handle "R" bit behavior correctly.
Miscellaneous Changes
Question: Should we put the required part for every host in separate document. Would highlight this functions. Several comments that this is not necessary.
ACTION: Document Editor will produce web page that lists required IPv6 specifications.
Reserved IPv6 Subnet Anycast Addresses / D. Johnson, S. Deering
Previously submitted to IESG for PS. Waiting for IETF last call.
IPv6 TCP and anycast address / Jun-ichiro Itoh
<draft-itojun-ipv6-tcp-to-anycast-00.txt>
Problem in TCP and anycast
- Anycast addr MUST NOT be used as source addr
- Can not disconnect TCP connection to anycast addr, by TCP RST
- Source address must match the SYN's destination
- Sender must wait till the TCP SYN timeout comes
Sender Receiver
S R, Anycast A
SYN
_______________
\______________\
/
______________
/_______________/
\ RST
When this situation happens
- Any situations possible
- No way to distinguish anycast addr
- Anycast addr in DNS database
- telnet host.foo.com makes connection to the addr
- Addr typed in by hand
- Addr given to client from some server
- We need a common way to disconnect TCP to anycast addr
Proposed Solution
- Transmit ICMP addr unreachable
- No restriction on source addr
- More quick disconnection possible
Sender Receiver
S R, Anycast A
SYN
_______________
SYN \______________\
/
______________
/_______________/
\ ICMP addr unreach
- Implemented into KAME IPv6 stack
- Works fine against BSD-based TCP stack
- Listen to ICMP errors, disconnect TCP connection if # exceeds limit
Comments: This should not be the behavior. TCP is not supposed to close connections on receipt of ICMP error messages. This error does not usually indicate "permeant" error. BSD is not a good model for this behavior.
Issues
- Per-address notification, not per-port
- OK since TCP to anycast is always disallowed
- Security
- Malicious router can disconnect any TCP session
- Problem is in ICMP, not new
- Future update in anycast to allow TCP?
- Implementations MUST make a flog to disable this
- Need your experience for non-BSD TCP
- Experiments welcome, at terminal room
- UDP6 suffers from this problem too...
- Example: name server on anycast addr
Deering: Was hoping there would be a proposal to change TCP to allow connection initialization using any anycast address. Special option in TCP to allow this. Asked if author interested in creating a TCP option. Reply: Likes idea but think there are security problems to deal with this.
Problem w/ UDP is not a severe as with TCP. Some UDP applications already work w/ multicast. DNS is a problem.
Would like to experiment with this, then submit an internet draft for consideration by the w.g.
RPC and NFS over IPv6 / L. Wu
RPC is supposed to be transport independent. Why would it ever be an issue for RPC over IPv6?
- RPC service lookup protocol
- Overview of RPC Service Lookup protocol
- What are the issues
- RPC-API
RPC service lookup protocol Overview
- RPC Service Lookup protocol enables client and server to bind dynamically.
- It was also know as PORT MAPPER
- Now it's evolved from the PORT MAPPER (version2) to RPCBIND (version 3&4). However PORT MAPPER is more widely deployed.
+----------------+
+--------+ <program, ver, protocol> | |
| |------------------------->| |
| Client | | Server |
| |<-------------------------| |
+--------+ <port> | |
| |
+----------------+
Version 2:
protocol = 32-bit integer, Port = 32 bit integer
Version 3&4:
protocol = string, port = string
RPC IPv6 Service lookup Issues?
- How to lookup IPv6 RCP services?
- Using PORT MAPPER
- Using RPCBIND
- Enforce IPv6 RPC services to use the port as IPv4 service?
Using PORT MAPPER
- Portmapper Request: <program, version, protocol>
- Proposing:
- Create a new protocol number to indicate services running tcp over IPv6 and udp over IPv6. There is no restriction in the protocol to be coincide with IANA number.
or
- Have PORT MAPPER listens on a different port than 111 for IPv6 service
Editor's Note: in slide, they don't mean changing TCP protocol number, just local identifier inside of implementation for port mapper.
Using RPCBIND
RPCBIND request: <program, version, netid>
- Proposing netid to be:
tcp6 - for service running TCP over IPv6
udp6 - for service running UCP over IPv6
Enforcing IPv6 service port
- If we are enforcing IPv6 service port to be the same as IPv4 service on a dual stack hosts. There won't be any issues with IPv6 service lookup.
- Proposing:
- Not to support the above idea, because it's not possible to differentiate a RPC service only support IPv4 on a dual stack host.
Discussion.
RPC API
- There are two major sets of RPC-APIs:
- Socket based RPC-API, as known as TS-RPC
- TLI/XTI based RPC-API, also known as TI-RPC
TS-RPC API
- Many APIs embedded sockaddr_in as parameters, for example:
clntudp_create(sockaddr_in *raddr,
rpcprog_t, prog,
rpcvers_t vers,
register int *sockp,
u_int sendsz,
u_int recvsz)
- Proposing
- Create new API that support sockaddr_in6
TI-RPC API
- It's not an issue for TI-RPC APIs since no sockaddr_in structure is exposed
SUMMARY
- Use TI-RPC APIs
- Have a separate service port for IPv4 and IPv6 service, and use RPCBIND for RPC service lookup with netid of TCP6 and UDP6 to specify services over IPv6
- Leave PORT MAPPER for IPv4 service lookup only. If want to extend it for IPv6, we have to resolve the issues.
- Current TS-RPC API is not able to support IPv6.
Tunnel Broker / A. Durand
Tunnel Broker / Server
<well known> Web page
+-----+ +-----+ +-----+
| | /| S | | B |\
| | / | | | | \
+-----+ Tunnel / +-----+ +-----+ \ IPv6 target
^ | Broker / +------+
| | +-----+ | |
| | +------>| B | IPv6 netowrk | |
| | / +------| |\ | |
| | / / +-----+ \4 +------+
1 | | 2 3/ / \ \ /
| | / /5 \ V /
| V / / \ +-----+ +-----+ /
+----+ / / \ | | | | /
| |/ / 6 | S | | S |/
| |=======================| | | |
+----+ +-----+ +-----+
Dual stack IPv4 host Tunnel server
The basic idea is to get the address of a tunnel broker from a web page (step 1 & 2), then running a tunnel broker protocol to the tunnel broker (steps 3 & 5) automatically obtain the address (similar to the way DHCP provides addresses) obtain a tunnel endpoint address of a tunnel server (step 6). The tunnel broker would communicate with the tunnel server as part of this process (step 4).
Discussion, many questions.
Plans on experimenting w/ this. Later might need to standardize a tunnel broker protocol.
Brian C: Does this replace 6over4 approach. Reply: No, it is complementary.
Meeting adjourned
None received.