2.3.6 IPNG (ipngwg)

NOTE: This charter is a snapshot of the 46th IETF Meeting in Washington, DC. It may now be out-of-date. Last Modified: 29-Sep-99

Chair(s):

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

Internet Area Director(s):

Thomas Narten <narten@raleigh.ibm.com>
Erik Nordmark <nordmark@eng.sun.com>

Internet Area Advisor:

Thomas Narten <narten@raleigh.ibm.com>

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@iprg.nokia.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:

Request For Comments:

RFC

Status

Title

 

RFC1886

PS

DNS Extensions to support IP version 6

RFC1887

  

An Architecture for IPv6 Unicast Address Allocation

RFC1981

PS

Path MTU Discovery for IP version 6

RFC1888

E

OSI NSAPs and IPv6

RFC2147

PS

TCP and UDP over IPv6 Jumbograms

RFC2292

  

Advanced Sockets API for IPv6

RFC2375

  

IPv6 Multicast Address Assignments

RFC2373

PS

IP Version 6 Addressing Architecture

RFC2374

PS

An IPv6 Aggregatable Global Unicast Address Format

RFC2461

DS

Neighbor Discovery for IP Version 6 (IPv6)

RFC2462

DS

IPv6 Stateless Address Autoconfiguration

RFC2463

DS

Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification

RFC2464

PS

Transmission of IPv6 Packets over Ethernet Networks

RFC2460

DS

Internet Protocol, Version 6 (IPv6) Specification

RFC2452

PS

IP Version 6 Management Information Base for the Transmission Control Protocol

RFC2454

PS

IP Version 6 Management Information Base for the User Datagram Protocol

RFC2465

PS

Management Information Base for IP Version 6: Textual Conventions and General Group

RFC2466

PS

Management Information Base for IP Version 6: ICMPv6 Group

RFC2450

  

Proposed TLA and NLA Assignment Rules

RFC2467

PS

Transmission of IPv6 Packets over FDDI Networks

RFC2470

PS

Transmission of IPv6 Packets over Token Ring Networks

RFC2471

E

IPv6 Testing Address Allocation

RFC2472

PS

IP Version 6 over PPP

RFC2473

PS

Generic Packet Tunneling in IPv6 Specification

RFC2497

PS

Transmission of IPv6 Packets over ARCnet Networks

RFC2507

PS

IP Header Compression

RFC2526

PS

Reserved IPv6 Subnet Anycast Addresses

RFC2529

PS

Transmission of IPv6 over IPv4 Domains without Explicit Tunnels

RFC2553

  

Basic Socket Interface Extensions for IPv6

RFC2675

PS

IPv6 Jumbograms

RFC2710

PS

Multicast Listener Discovery (MLD) for IPv6

RFC2711

PS

IPv6 Router Alert Option

Current Meeting Report

November 1999 IETF Meeting
Washington, DC
USA

Bob Hinden / Nokia, Steve Deering / Cisco
IPng Chairs

Minutes taken by Bob Hinden and Allison Mankin.

AGENDA (WEDNESDAY, November 10, 1999)
- Introduction / S. Deering
- Review Agenda / S. Deering
- Document Status / R. Hinden
- DNS A6 Record, ipng/dnsind / M. Crawford
- ICMP Name Lookups / M. Crawford
- Summary of Tokyo Interim Meeting / S. Deering
- IPv6 extensions to RPC / S. Majee
- TAHI IPv6 Interoperability Test Report H. Miyata
- IPv6 Socket Scrubber / C. Williams
- IPng Statement on Privacy / S. Deering
- Privacy Issues w/ Addrconf / Anonymous

AGENDA ( THURSDAY, November 11, 1999)
- Wireless Telephony / C. Perkins
- Connection/Link Status Investigation (CSI) / H. Kitamura
- Unidirectional Link Routing / H. Afifi
- Source Address Selection Draft (R. Draves) / S. Deering
- Text Syntax for Scoped Addresses / T. Jinmei
- IPv6 Inverse Neighbor Discovery / A. Conta
- Local Scope IPv6 Networking / R. Hinden

Wednesday, November 10, 1999

Introduction / S. Deering

Steve Deering opened the meeting.

Review Agenda / S. Deering

Reviewed agenda.

Document Status / R. Hinden

RFC: 2675 Jumbograms, 2710 MLD, 2711 Router Alert

IESG approved since last meeting - Router Alert, MLD. Format for Literals - got a good consensus after some pain

Still in IESG for DS -

RFC2372/2374. Remaining issues - document implementation issues of scope multicast forwarding and how do you know if you have enough experience with an architecture document to go to DS?? Will need to keep working w/IESG to "help them not worry about this too much...no new architectural concepts here..."

About 18 sub-TLAs have been assigned by registries. Most have been outside US (except for about 2) - consistent with appearance that ops deployment may be not in US first.

With IESG for PS -

RR needs updated draft, last set of comments came after draft closing this IETF...

DNS extensions - needed new draft, other related DNS docs approved by IESG - a new draft has been issued and short WG last call will start now, along with notice to some place like namedroppers. Should go back to IESG in about a week from now if all well.

ACTION: Document editor to start one week w.g. last call for advancing the DNS extensions draft to Proposed Standard.

With IESG for Info -

GSE - IESG discussing security issues / conclusions. Authors planning new draft, slightly broadened scope, not just security.

Bound asks why, if it's just a very good job of minutes, it hasn't come out. Narten : when we first did it, it was minutes of rejection of GSE proposal. Then seemed to us to talk in more detail about separating identifiers from locators, so subsequent drafts downplayed GSE points. People who are reading now don't see the basic reasons GSE shouldn't be moved forward anymore.

IPng WG Last Call for Info but not sent to IESG

Initial Sub-TLA assignments - action we wanted has happened. Can find the assignments on IANA page. Update draft to match binary justification text to IANA page, then send to IESG for informational, so it can be in permanent form as RFC - IANA can ref it instead of timing out...

ACTION: Reissue Initial Sub-TLA Assignment draft, then submit to IESG for informational.

Flexible Addr assignments - author owed comments by Hinden.

Case for IPv6 - there is a new draft out. Deering is in charge of making it get published ASAP. Comments to Charlie Perkins within next week because doc has been lingering IESG will get then. Not sure if IETF Last Call will be done, maybe not as only Info.

IPng WG docs ready for WG Last Call -

IPv6 over Ether/FDDI/TR/ARCNET/PPP to Draft - template will come for filling out for implementation/interoperability testing.

ACTION: Document editor to create template for IPv6 over Ether/FDDI/TR/ARCNET/PPP w/ input from authors. Once implementation data is collected, start w.g. last call for Draft Standard.

ARCNET - Ignatios Souvatzis NetBSD, internal Nokia (used inside machine, but will see if possible to do an interop with NetBSD impl)

See what can go forward based on experience we can get.

ICMP Name Lookups for Experimental according to plans, but Matt will speak to this.

DNS A6 Record, ipng/dnsind / M. Crawford,

Recent Changes - No "A" or "AAAA" add. Section processing

A6 additional info takes priority over NS - A, then A6, then AAAA - you might end up with a set of addresses but not complete set, resolver can tell, application may or may not know.

Guidance for clients about configuration options/default/only if no configurability.

Stuff go into transition document

ICMP Name Lookups / M. Crawford

Recent Changes to ICMPv6 - rev 05 -

Added 5th query type for v4

CRC-32 out; MDF5 in. Names to be canonicalized as in DNSSEC before hash

Names in DNS wire format, not plain strings - proofs us against future label types that may be the names

Multiple names be returned

Each returned address has its own TTL.

Apologizes to early implementors for shuffling around the flags.

Comment received - if ask node for its name, no such thing as TTL for a name, it was asked to allow non-zero TTL for name.

Hinden asks why 5th query type - use in mind? Metzger: has clients who may be able to use.

Does this document go on experimental or standards track? Polls for existence of strong feeling as to which.

Bound feels strongly it should go to standard, but IESG might be prudent to ask for implementation before PS, as is their option. "I'm in a tough place, because I think it's a good idea, man, but I also see the ramifications." So do standards track after some quick hacks out there.

Durand: did implementation, not bad match to current draft. Suggests short experimental phase maybe, but not long

Metzger: it's working in several stacks, lightweight, probably useful, what downside to stds track.

Nordmark: if useful, must also check for gaping holes, e.g. security. Security is IPSEC, not less secure than DNS. I don't see any formal reason not to go to PS.

Bound: may be a way to fix some of the scoping issues tomorrow. Would like to defer to Bob Halley because it affects the resolver. If hacks haven't been done by Sun, Compaq, HP etc - want a vendor vetting.

Nordmark: we have ways of injecting other names services, like NIS, so no-brainer to add this as another one of them. Some want to integrate in resolver, maybe, but...

Durand: How we did it.

Hinden: Maybe more work associated because of scope discussion tomorrow, but heard rough consensus for standards track for it.

Summary of Tokyo Interim Meeting / S. Deering

Chairs summary of Tokyo Meeting.

Productive. Concluded that multi-day interim meetings are usually much more productive than these because of lack of time pressure, chance to drill down in depth.

Action Items/Decisions

IPv6 address scope model Deering to produce a draft, hopefully by DC. Hopefully failed. Invites Brian Zill to collaborate, based on his writing on mailing list.

Multihoming overview

Suggestion that authors look for more descriptive terms than "multihomed", e.g. multi-addressed, multi-interfaces

Had divided MH area into near-term host solutions (soon/host-based), longer-termed host-based with new concepts involved, and router-based approaches (routing system only).

Main document for 1 is Rich source addr selection doc and produce new one on dest addr ordering (by DC) - he has succeeded in getting his doc out in time - merged into one

Another issue - policy control over MH behavior
- no specific action we can't always write ordering of addresses
- because external policy may want to influence. How to provide hooks
- for this. Rich has good example in doc, others need to think about.

Long-term -
- continue work started by MH design team on enhanced API (e.g. connect to DNS name, bury the address questions below transport level, protocol independent way. Continue this work
- Peter Tattam nice proposal to use TCP to deal with multiple addresses. Simple, surprising not thought of before. During SYN exchange, tell all your addresses. If other addresses are used during connection, can cope. Doesn't deal with arrival of new addresses (as in renumbering) , but does take advantage of multiple addresses available for a machine. Will produce draft before next meeting. Contribute to transport area.
- Maybe mobile IP has all mechanisms need for MH - it looks promising but it still has problems that have to be resolved. Mobile IP falls back on home address, this doesn't have that, needs an alternative robustness measure to make up for lack of HA.

Ecklund: how about including several addresses in HA option, merging these? Extend to routers for help in load-balancing, in current spec (of what?)

Perkins: want mobile to be considered, work out details, or not? Deering: didn't cause us to stop working on other solutions, neutral. If mobile IP people do, that's great, not asking them to especially.

Router-only -
- 2260/itojn versus Jessica Yu's SMPL
- viewed that both could be useful, depending on ISP wishes. Asked both to flesh out and continue both. Not sure if will be stds track or BCP or what. Asked authors to use more descriptive names, e.g. "tunnels for MH site fallback", "prefix prop agreements for MH site fallback"
- RR protocol alone is insufficient (using different TTLs for prefixes to give pref).

Site-renumbering model was presented by Hinden -

Claim is made that we made it easier, but renumbering is actually fairly large problem, e.g. outside IP stack, what is process to go thru to renumber a site. Bob showed steps, time intervals. Pragmatically what it supports, what expectations should be (not to be able to renumber every hour...) Bob is going to produce a doc (Info?) by next IETF.

Plug and play architecture holes was presented by Deering -

Resolved to present at zeroconf WG and he did so. IPNGWG encourages WG submissions on this topic!!!! Some uncertainty if new work should be coming into this group. Lack of having decision about that should not stop anyone submitting specs. Will work out later if new WG.

IPv6 API and user interface issues -

Two general areas - making sure you can provide scoping info when using less than global, that API has hooks enough for that - and at user interface level, can we allow user-friendly names for sites, advertised by multicast (e.g. router advertisements). Proposal for extending literal address syntax to afford that will be presented later today.

Clarify use of scope id field in Basic API.
- Generalize if ID space (numeric and character strings to include zone Ids/name strings) 3 more bullets (get presentation)

IPv6 extensions to RPC / S. Majee

Sumandra Majee, Sun, smajee@eng.sun.com, IPv6 Extensions to RPC

Extending RPC to IPv6 will help it to be deployed sooner.

Design considerations
- Backward compatibility for both source and binary
- should work without changes over IPv6
- source more able than binary. May add new functions to enhance but no function prototype change. Not tell application it is IPv6

Two problems - ONC+RPC

Two different major impls -

TI (Transport Independent) and TS (socket-based), popular choice, but present Sun implements only TI.

Issues with RPC
- Transport selection, IPv6 or IPv4? Application smart enough to
- choose, can RPC address lookup and registration service TS-RPC have
- to change a lot because actually exposed to sockets.

Transport Selection in TI-RPC

Two new netids for UDP/IPv6(udp6) and tcp6
- don't' have to name them this
- it is local to server. Order of entries in xxx.rc determines which will be picked up first.

Example:
- udp6 tpi_clts v inet6 udp /dev/udp6 tcp6 tpi_cots_ord v inet6 tcp
- /dev/tcp6

Most of users of library used it with IPv6 with no problem at all, no work - a few complicated apps had repercussions.

Transport Selection in TS_RPC

Use getipnodebyname - no other way to do it.

RPC Address Lookup and Registration - 'the fun part'
- RPC uses rpcbind or portmapper (more popular). Client side to access gives prog_number, version, proto gets port

Only udp/tcp ports are available. Cannot tell which IP, because it doesn't see tha far down.

Solving Portmapper - most used - quite a few possible solutions, e.g. use different portmapper port for the IPv6 ones, but it was desirable not to for backward compatibility. So solution that has been proposed, not really implemented yet -
- when IPv6 enabled client side comes up it probes remote portmapper with NULL RCP request to find out if there is even IPv6 server. Then probe remote RPC server. UDP-based requests get ICMP port unreachable (not guaranteed, though).

Problems of dropped ICMP messages though port could be there.

Also service needs to use same port for both 6 and 4 for this to work.

Using RPCBIND -

When client requests, netids guied reply. Universal address format is literal, presentation format. Only other change, which is if no 6 universal address should fall back to 4.

New control options -

Enhancements for IPv6 case. Traffic class. But not defined. It would be good to know what should do.

Seems like a good time to add some server side control, e.g. bandwidth allocation.

RPC API -

Don't touch API in TI. TS-API needs to work by looking at sin_family.
If ANYSOCK, give a 6.

Server side API change in TS - similar

Summary - if people are implementing RPC/IPv6, used RPCBIND at least, not portmapper, and best, also go with TI.

Deering: in syntax, was it considered to not use address followed by colons? Ans - used a square bracket internally, and actually slide is wrong.

Do a draft for this in WG? Tim: what does RPC WG want to do? Ans: draft by him and a guy from SGI. Chair wants it to be in RPC but also covered in IPNGWG.

TAHI IPv6 Interoperability Test Report H. Miyata

Hiroshi Miyata, TAHI

Objectives / 1st interop event in Tokyo /

Tools and scenarios are freely available and are intended to promote quality

Interop event - 9/26 - 10/1 - 2.5 test days and 3 days that were overlapped by Interim meeting.

15 groups - 18 impls - France, Japan, US, Denmark, Korea, Japan

Menu: conformance/interop test using scenarios/ad hoc network/interpretations.

[Pictures of the event.]

Ad hoc network topology was made with 14 routers and 10 hosts - BGP4+ E/I, RIPng (ATM backbone among the routers, some also using Ether backbone)

Introduced conf tests last time, this time interoperability. Current:

Host - 5 scenarios - focusing on basic spec (onlink, offlink...) Router - 13 - basic spec, working with hosts, and routing (BGP4+ and RIPng)

Tools - packet analyzer - input tcpdump file, output original format (wire).

Traffic generator - Manager/Agent style Mgr controlling scenarios

Traffic generator is under test, packet analyzer was just finished this morning.

Free 228/32/33 +KAME

Showed web results of an output file of a flow (from PA) : stands for solicited node address, * for unspecified address.

Table of what available now - will have to ask him for the slide if not clearly at www.tahi.org

Future - enhance more and plan next test event.

Perkins: plans for tests of mobile IP? Not at this time.

Will show tools to people in terminal room.

Agenda Change - move CSI and unidirectional link routing to 2nd session if no time today - go from scrubber to Privacy.

IPv6 Socket Scrubber / C. Williams

Carl Williams, Sun, IPv6 Socket Scrubber

Comment on mystery of name even to Hinden. A couple of years ago IPv6 program manager in Sun went out to get applications ported internally. To do so, had to make porting tools. Manager/she was previously Y2K manager and based this on y2k code scrubber.

Basically this searchers for IPv4 socket API code through recursive directories - uses egrep, important when users extend the set of patterns.

It's not a translator. Limitations - not guaranteed to find all* lines that need porting. (For instance, old code that uses ulongs to represent addresses).

Example - patterns characterized in 5 different areas - constants like AF_INET, IPv6 functions such as gethostbyname, IPv4 dat structures such as sin_family. Also macros and ioctl constants. Have also included TCP and UDP and IPv4 MIB structures. Would like feedback to add missing patterns.

Output of an execution - into a primary.results and secondary.results file - the latter are problem patterns that if searched for would cause too much spurious hits, so separate them out (for less intense inspection, presumably)

Show the filenames with no problems as well as those with problems. Show segment of file with problem.

Net output is name, lineno.

Eric ran on Solaris source base and found lots of AF_INETs not expected. Jim Bound that he had searched his source bases with similar results.

Config files - 5 containing patterns. Transcribe info from slide.

Has options to substitute for provided pattern files.

Summary - ease porting transition. Link to Scrubber source code and man page will be at www.sun.com/solaris/ipv6 within a couple of weeks.

Should work in most environments. Doesn't work, run XXX in system file and see what changes needed.

Code derived from Y2K scrubber - was written in C.

Carpenter: could you publish a list of things with which you found problems, not to expose proprietary. Would help others. Response: use the documentation, porting guide. Example - broken IPv4 applications where Telnet does a gethostbyname and won't go beyond first address - scrubber can't find this itself. Important for v6.

Metzger: no restrictions on use? Response: not on download etc. There is a license on it.

IPng Statement on Privacy / S. Deering

Privacy Talks - intro by Deering - a few weeks ago, reports in press about IPv6 addresses carrying MAC addresses and concerns similar to Intel serial numbers in chips that would possibly be sent over net. Had identified issue back in Feb (Grenoble) and had a draft on a method for using random numbers instead of EUIs. Not to forget we support the stateful methods too, DHCP. Was good we had done it, but reporters weren't aware. Chairs put up statement on IPng Web Page. http://playground.sun.com/ipng

Expect a lot of browsing won't carry unique serial numbers, though explain good of easy autoconf [is random much less easy] and need for persistent addresses for servers. I'm happy to have a unique phone number so people can call me, but not so happy that my number goes in all my calls for caller-id, similar. Coincidence of megaco wiretapping stuff - reporters view that IPv6 is attempt to make internet wiretappable. Opposite is true - strong e2e encryption mandatory implementation was to make wiretapping not* typical.

Privacy Issues w/ Addrconf / Anonymous

Note: For reasons of privacy, we werent' told in advance who would do the presentation]

Privacy Exts. By 00:04:ac:25:6b:83 Narten@raleigh.ibm.com

You don't know me, but I'm concerned about privacy.

Brief history.

Version 00 in Oslo
- Simple approach: change interface identifier (and address) at reboot (only)
- all addresses use same interface identifier
- Draft doesn't distinguish client-initiated communication (where anon addresses make sense) from comms targeted at server (where anon addresses make no sense
- Many machines will be both clients and servers: need both simultaneously.

October - world takes notice

Version 01 appears

Current draft
- Assume devices are both clients and servers
- some addresses be anonymized
- Generate link-local and site-local addresses as in RFC2462, only anonymize global.
- Generate global server address using rfc 2462 addrconf, but deprecate immediately so it is accepted for incoming but not used for incoming!
- Generate temporary, anon addresses - current recommendation is to generate a new address once a day.
- Provide configuration knob to allow end user to change time between new address generations (even to once per minute, if desired...).
- When you are done with an old one, deprecate it so it won't be unusable, just not used for initiating.

If this was very widely deployed, it would be very difficult to do correlations at servers, even if infrequent. [Did not mention address depletion issues...]

Details
- Generate pseudo random seq of IF identifiers, each iteration gens next id in seq. When device boots first time out of box, gen 64 bit random number, save in stable storage as history value
- Combine 2462 interface id with history value Compute MD5 hash Take leftmost 64 bits and create id Form global addr, run DAD, repeat up to 5 times if DAD reports in use Save rightmost 64 bits of md5 has in stable storage for next iteration.
- Intended to make it harder to predict - table or precalculated sets might have risk. Also if nodes generating addrs at random with same algorithm and not doing this, collisions might be more likely.

Open issues -
- Some servers req that client be in DNS (PTR and A) - if not, no access. DNS name is identifier, so random address needs to correspond to random DNS name -n.b. if keep old DNS name, no privacy anyway...DNS server generating randoms not too far along.

When should old anon addr by invalidated?

- When higher layers no longer use address - not-so-hard for TCP (because can search TCBs), only apps know in UDP case

Discussion:

Perkins - why do you have serial reuse policy? Might want to be able to use multiple ones, application change to a new one, go back to old.
Response - the more we encourage apps to do things, the more risk they don't go here as we need them too. Perkins - not encourage, just make possible. Bound - this is not networks' choice, but business choice.
Narten - if we don't act/standardize, we could find no one implements
Nordmark - base-level mechanism like this, provide right for application to do other things, but make this the base. Durand - what if you are home and get a delegation of /64? Narten - always-on connections the first /64 id's your house, so this foxes some privacy. Could imagine ISPs randomizing some routing bits for you, if this was viewed as sufficient problem. Bound - what status - mandatory requirement to ship in addrconf? Narten - vendors could elect as optional extension, for instance not particularly compelling to router vendors.
Bound -would I be compliant if I gave choice at IPv6 setup whether you want this or not? I don't want my vendor to mandate that I have privacy. Someone - default means you are protected till you turn it off. Concerns that vendors might be worried about liability if you turned it off.
Ecklund - to implement, extension to ND to say you must use it and your addresses get deprecated until you start doing it - add RA flag to enable this. Narten - it's in the ID.

More about invalidation issues - Anonymous addresses complicate operations/debugging. Should site admin specify policy allowing/disallowing use of anon addresses?

Someone else - as a network administrator, this is much harder for statistics, billing information.

Deering - most of privacy issues arise in residential, net admins in enterprises where rights are different, control

Same someone - users controlling their host os can override policy.

Hinden - this falls into security policy of site.

Nordmark - social problem. Not technical problem. Stop by firing if people "misuse"...

Narten - take hum vote on ability for site admins to disable. Seems to pass.

Zill - maybe RA not best way to do it. Awful lot of things in sites have another method, often os specific. They already have bits suitable to it, he agrees with Narten.

Someone - brought up at RUN WG. Accumulation of information/caching is policy - limiting isn't something technical.

Deering asks him to forward name of draft.

Perkins - need for privacy in addressing is not necessarily tied to stateless, should have a way to get a randomized address from DHCP.

Narten - yes but that is separate decision.

Nordmark - as to where to put knobs, we have knob about whether to use DHCP, good to have knobs together.

Deering - one of the press reports seemed to be saying ACLU was against IPv6 deployment. Letter had no reference to IPv6.

Thursday, November 11, 1999

Wireless Telephony / C. Perkins

Outline of Presentation
- Advantages of IPv6 for Future Telephony
- Challenges of Wireless
- Header Compression
- UDP Lite
- AAA
- Using DNS for phone numbers
- Feature management
- Interface with IPv4

Advantages of IPv6 for Future Telephone

[figure]

- Number of "telephones" will exceed IPv4 address space
- Mobility is nicely solved by Mobile IPv6... including presumably, smooth handovers
- Autoconguration, leading to always on
- Mandatory security for voice handsets
- Presumed easier routability

Challenges of Wireless
- Errors leading to lost packets
- Bandwidth constraints, requiring spectral efficiency
- Base station selection

Note that these problems do not necessarily fall within in the jurisdiction of IPv6

Important to be able to move compressing state during a handoff. Not clear how all of these are solved or how to get full spectral efficiency.

Solution Components
- Header compression
- UDP lite
- AAAv6
- Key distribution and Management
- DNS
- Call Control
- Integration with WWW (webtone)
- Transport friendly IPSEC ESP/AH
- Realtime mobile optimized

Header Compression
- RFC 2507
- ROCCO
- robhc BOF on Tuesday

Report from M. Degermark on robust header compression BOF. It is likely there will be a w.g. in this area. It should be possible to compress IP,UDP,RTP to two bytes. IPv6 compression should be better than IPv4 due to it's simpler header.

UDP Lite
- Allows errors to get past UDP checksums, to tolerant applications
- Only enable by direct action of application, not the default
- Only makes sense with certain tolerant framing protocols

M. Degermark added that there might be BOF on UDP lite at the next IETF.

AAAv6
- Allows local connectivity to be controlled depending upon validation by trusted remote service
- Lack of foreign agent removes IPv4 target for protocol design
- IPv6 control must be exerted on destination cache updates at default router
- Possible strategies include:
- Extensions to Router Solicitation, Advertisement
- Requiring DHCPv6 interactions
- AAA redirect along with additional router logic
- Desirable to perform authorization for network access, not radio link establishment

Key Distribution and Management
- Does AAA create key between home agent and mobile node?
- How does local router get key with mobile node for smooth handover?
- Mobility introduces need for local service fulfillment; how is authorization handled?

What is Next?
- Are relevant work items being worked on in other working groups?
- Is there interest for a BOF in Adelaide?
- Is their interest for a w.g?
- Framework document?
- Proposed BOF charter: http://www.iprg.nokia.com/~charliep/txt/ietf46/ip6tel.txt

S. Deering wasn't sure that a w.g. need to be formed. This might be too focused on on telephony. Is an important issues.

Nordmark: Thought that important to make sure IPv6 can run directly over wireless (instead of PPP over wireless). Also, not sure that new w.g. is not necessary. Perkins thinks it is important that there be a place where overall issues are discussed. Nordmark: Do need to find way to coordinate work in this areal.

Comment: Thinks this is good idea and important for IPv6. This is good way to let other people how IPv6 is good way to solve this problem.

Brian Z: Not sure new w.g. need to be formed, but need a steering group to help coordinate and prod other groups to do this work.

Comment: Boot strap problem in IETF. Need to do system design before one can design components. IETF usually focuses on components.

Comment: Thinks problem of cellular telephone are different from normal IP environment. Good to focus on this problem.

Christian H: This would be a good job for the IAB. Deering reported that the IAB is planing a workshop in this area. Not sure when it will happen. Bob Hinden has volunteered to help organize IAB workshop.

Narten: Thinks it is premature to have w.g. Need to work out more details of work will before we can do this. Some of the work items seem to belong in other working groups. Thinks a framework document would be very valuable.

Comment: IAB workshop input would be good. Then address issues in IPng and other w.g.'s.

Connection/Link Status Investigation (CSI) / H. Kitamura
<draft-ietf-ipngwg-hbh-ext-csi-02.txt>

Generic framework to collect real time status information of nodes along both outgoing and incoming paths efficiently with minimum number of packets.

What is new
- Simplified header format
- One new IPv6 Hop-by-Hop option
- CSI option
- Three new ICMPv6 messages
- Status Request / Status Reply
- Status Report

[ example slides]

What's new
1. Simplify the CSI option header format
- Page and Bitmap fields are deleted. (Alignment: 4n+2)
- Record format in Data Space is changed
- Mandatory component of each Record is introduced
2. Introduce two types of Operation Modes
- SPSR (Single-Probe/Single-Reply) for normal environment
- SPMR (Single-Probe/Multiple-Reply) for problematic environment.
3. Refine the method to specify Investigation Data Types
- Hierarchical method is used to specify acquired data type.
- Define the "Basic Investigation Definition Set"
- Ideas of "Elementary Investigation Data Components" and "Combined Components Group" are introduced.
- Investigation scenarios are clarified.

[header format figures]

[ example slides]

How to specify Investigation Data Types (or Investigation Scenarios)
- Use two hierarchical fields

- Defines only "Basic Investigation Definition Set"
- New definitions of [Invest. Class] can extend the CSI mechanism easily

[figures]

Where is intelligence or complexity?
- To intermediate nodes (routers):
- No complex and intelligent operations are required
- Only simple data acquisition operations are required
- They are not relevant to performance issues
- No high processing speed is required.
- Reliability of data is not dependent on it
- To a utility application on the initiator node:
- Intelligent operations are required
- to receive Status Reply and Report(s)
- to analyze collected data
- The CSI mechanism is simple enough and
- easy to implement to any IPv6 nodes.
- Intermediate nodes

Showed results of implementation

Conclusive Questions
- Do you want to
- investigate the "Incoming" path?
- investigate by the efficient (minimum packets) method?
- execute the "Record Route" operation of the path?
- measure the consumed real-time bandwidth?
- verify the status of the communication path?
- Why not use the CSI mechanism?
- Request to accept the CSI mechanism as a WG item

Comments/Discussion:

Christina H: This is a great denial of service attack. Once packet will generate many packets in response. This is a serious security problem.

Narten: Disagrees that this is small amount of overhead in routers. Also, some of the information gathered is considered proprietary by ISP's. SNMP can be used for this. ISP's will not want to have open access for this kind of information.

Brian Z: Really dislikes this proposal. Anytime you send one packet out, it is very bad to get multiple packets back. Also doesn't think router owners are going to want this kind of information to be made available. Can accomplish the same thing with a route header in a traceroute.

Deering: This proposal has been presented several times before and the same comments have been made. Thinks need to listen to comments.
W.G. does not seem to want to adopt this because of technical problems.

Chair polled w.g. Result was that working group does not want to adopt this as a working group item.

Unidirectional Link Routing / W. Dabbous

UDLR v6
- Kame code modification to support UDLR @IRS, COIAS projects
- Drivers modification to recognize IPv6 code
- Tested with vicv6 over INRIA LAN/satellite link.
- The modifications for the receiver code are made available to Kame
- URL will be announced soon on ipng and on udlr mailing lists (udlr@sophia.inria.fr)

UDLR Architecture

[ figure ]

Tested w/ multicast. Added code to KAME stack. URL will be announced next week on IPng mailing list. If interested send mail to uldr@sophia.inria.fr

Default Address Selection for IPv6 (R. Draves) / S. Deering
<draft-ietf-ipngwg-default-addr-select-00>

Source Address Selection and Destination Address Ordering
- Minimal requirement for all implementations
- Automatically pick "reasonable" source and destination addresses
- Configuration/policy is possible but not required (except for default policy) Complement other approaches

Framework

getaddrinfo/getipnodebyname: IPv6 network layer:
+---------------------+ +----------------------+
| Destination Addr | | Source Address |
| Ordering | | Ordering |
+---------------------+ +----------------------+
^ ^
| |
| +-----------------------+ |
| | Policy Table | |
| | | |
+-----| Configurable Admin |-----+
| Preferences |
+-----------------------+

The algorithms do not override application / upper-layer choices.

Default Policy Table
- Implementation SHOULD be configurable. If not configured, they MUST operate according the the default policy table:

Prefix Precedence Label MatchSrcLabel
--------- ---------- --------- -------------
fe80::/10 40 1 1
fec0::/10 30 2 2
::/0 20 3 3
2002::/16 10 4 4
::/96 10 5 5

- Use native source address with native destination addresses, 6to4 sources with 6to4 destinations, and v4-compatible sources with v4-compatible destinations

- Prefer using native addresses to communications using either 6to4 or v4-compatible, but no preference (by default) for 6to4 addresses over v4-compatible addresses or vice versa.

Discussion... Suggestion that IPv4 mapped address should have an entry in this table, but have least precedence.

Destination Address Ordering
- Prefer dest that have a "matching" src address
- Prefer dest that are higher precedence
- Prefer dst w/ longer match against src address
- Otherwise leave in original (DNS) order

Comment that there may be a bug here. Some confusion.

Source Address Selection
- Prefer sources that "match" the destination
- Prefer a source that IS the destination
- Avoid deprecated addresses and addresses of different (especially insufficient) scope
- Prefer sources with longer match against the destination

Examples Scope vs. Deprecated
- Site-local destination. Source A is deprecated site-local, source B is preferred global. Choose B.
- Global destination. Source A is deprecated site-local or global, source B is preferred link-local. Choose A.

Examples - Transition
- 6to4 and native destinations, 6to4 source. Choose 6to4 destination.
- 6to4 and native destinations, 6to4 and native sources. Choose native destination and source.
- 6to4 and native destinations, preferred 6to4 and deprecated native sources. Choose 6to4 destination and source.

Example - ISP Preference

+---------------------+ +----------------------+
| ISP 1 |-------------| ISP 2 |
|2004::/16, 2006::/16 | | 2005::/16 |
+---------------------+ +----------------------+
/ \ /
/ \ /
+---------------------+ +-------------------------+
| Site A | | Site B |
| 2004:A::/48 | | 2005:B::/48,2006:B::/48 |
+---------------------+ +-------------------------+

A wants to use IPS 1 to reach B

Prefix Precedence Label MatchSrcLabel
--------- ---------- --------- -------------
::/0 25 1 1
2004::/16 25 1 1
2006::/16 20 1 1

Example - ISP Preference

+---------------------+ +----------------------+
| ISP 1 |-------------| ISP 2 |
|2004::/16, 2006::/16 | | 2005::/16 |
+---------------------+ +----------------------+
/ \ /
/ \ /
+---------------------+ +-------------------------+
| Site A | | Site B |
| 2004:A::/48 | | 2005:B::/48,2006:B::/48 |
+---------------------+ +-------------------------+

B wants to use ISP 1 to reach A, but otherwise ISP 2:

Prefix Precedence Label MatchSrcLabel
--------- ---------- --------- -------------
2004::/16 25 1 1
2005::/16 25 2 2
2006::/16 25 1 1
::/0 20 2 2

C. Huitema: Suggestion to only use longest match within one preference. Not between preferences.

Controversial Issues - 1
- Is this a proper subject for an IETF standard? If so, can the standard use MUST yet allow application / upper-layer override?
- Proposal: Yes & Yes.

Comments:
Nordmark: Thinks we do need to define the default.
Brian C: Thinks the text needs to allow other behavior, but make sure this is the default. Suggestion that contents of default table should be IANA parameters to make it easier to change.
Comment: Concern that it might be a lot of cycles to do the address selection procedures. Won't be free. Some applications will want to do this on their own.

General consensus on YES, YES, but need to be careful on wording and need implementation experience.

Controversial Issues - 2
- Under what circumstances can the IPv6 network layer use a deprecated source address?
- Proposal:
- When application / upper-layer specifies.
- When policy specifies.
- When sending to that address.
- To avoid insufficiently scoped source address.

Comment: What is the purpose of the policy override on this slide?
Discussion..... What is meant by Upper layer need to be clearer.

Controversial Issues - 3
- Under what circumstances can the IPv6 network layer use a source address not assigned to the outgoing interface?
- Proposal: Only in routers or when the application / upper-layer specifies.

Discussion. Need complete discussion on mailing list. Not enough time.

Open Issues
- Interactions with mobility
- When to use a home address?
- Are home addresses assigned to an interface?

Text Syntax for Scoped Addresses / T. Jinmei (15 min)
<draft-ietf-ipngwg-scopedaddr-format-00.txt>

Contents
- Problems
- Our Proposed Solution
- Implementation Examples
- Related Issues

Terminologies
- Scope
- node-local, link-local, site-local, organization-local, global...
- Scope identifier
- a particular instance of a scope
- "link identifier" will also be used as an identifier of a link- local scope
- zone ID, perimeter ID, region ID,... are not used in this presentation

Problems
- An IPv6 scoped address does not provide sufficient information on a scope boundary.
- "ping fe80:: 1" would confuse the ping program if you have 2 links

?? ??
<--- +--------------+ --->
--------|"ping fe80::1"|------ -
linkA +--------------+ linkB

- an identifier of the link should be provided to the program
- same kind of problems arise in site-local addresses
- It's hard to reuse scoped addresses using "cut and paste".
- e. g: lookup a routing table and telnet to a gateway
- a link- local gateway can't be "cut and pasted" without a link ID

Approaches so far
- Specify a scope ID as a command line option or something
- e. g. "ping -S 1 fe80::1"
- need extra code for each application
- does not help "cut and paste"
- you can't always use the same option for this purpose
- Introduce a "default" scope ID for each system
- Not a complete solution
- you should still specify the ID when using a scope other than the default

Proposed Solution
- Introduce a new format for scoped addresses:
- <scoped_address><delimiter>< scope_id>
- Example:

- Should be applied to both unicast and multicast
- Extend library functions that translate between a hostname and a numeric address
- takes a literal address in the extended format
- returns a numeric address structure that contains the scope ID
- Note: we don't recommend you to use any particular library functions

The Benefits
- An application can just use the extended library functions
- it is not necessary to extend present applications.
- A user can easily "cut and paste" scoped addresses
- the address format itself has enough information of scope

Implementation( 1) Address extension
- KAME's extended format for scoped addresses
- (currently) for link-local addresses only
- interface name as link ID
- assuming 1to1 mapping between links and I/Fs
- "@" as the delimiter
- e.g. fe80::1@ne0=fe80::1 on the link specified by ne0

Implementation( 2) API extension
- Use sin6_scope_id to specify a scope (i.e. link) ID
- kernel sends a packet to the link specified by sin6_scope_id
- kernel sets a link ID of a received packet to sin6_scope_id
- KAME's getaddrinfo supports the extended format
- takes an address as a hostname in the extended format
- sets the according scope ID to the sin6_scope_id field
- getnameinfo is also extended
- takes sockaddr_in6{}
- returns a literal address in the extended format.

Implementation: How it works

[example slide]

Examples
- ping command
- needs no option to handle link- local addresses

% ping6 fe80::290:27ff:fe3c:1817@ef0
PING6(56=40+8+8 bytes) fe80::2a0:24ff:fe66:1350-->fe80::290:27ff:fe3c:1817
16 bytes from fe80::290:27ff:fe3c:1817@ef0,icmp_seq=0 hlim=64 time=0.784 ms

- output of netstat -rn command

Internet6:
Destination Gateway Flags Interface
default fe80::5254:ff:fedc:5217@ef0 UG ef0

- telnet command

% telnet fe80::5254:ff:fedc:5217@ef0
Trying fe80::5254:ff:fedc:5217...
Connected to fe80::5254:ff:fedc:5217@ef0.
Escape character is "^]".

Related (Open) Issues (1)
- We'd better to define specific syntax for portability.
- What is the desired delimiter?
- KAME's "@" seems not good
- other candidates
- <scope_id>/<address> (used in MSR)
- <address>-<scope_id>
- are alphabetical characters better?
- [S|s]<scope_id>:< scoped_address>
- is "S12A:FEC0::123:4567:89AB:CDEF" easy to read?
- What is the desired order of <address>, <delimiter>, and <id>?
- is <scope_id> the most significant part?
- if so, should it be placed before <address>?

Related (Open) Issues (2)
- What is the desired identifier?
- interface name
- not so intuitive
- (sometimes) even confusing; how to distinguish I/ F, link, site, ...
- numerical identifiers
- tend to change, not intuitive
- should an identifier be unique in a scope?
- e. g. a company name for a site
- name distribution (or discovery) problem
- how to avoid confliction
- Scoped Addresses in URL's
- http://[ fec0::1234-bar. com]:80/index.html would be better than
- http://[ fec0::1234]:80/index.html

Related (Open) Issues (3)
- Many API issues
o extension for getipnodebyname(), getipnodebyaddr()
- need another structure?
- semantics of sin6_scope_id
- should be separately discussed

Deering asked w.g. to see if wanted to continue this approach. Result
was that group wanted to make this a w.g. item and continue developing
it.

Question was should these scope identifiers go to the DNS or just be
kept locally. Discuss on the list.

IPv6 Inverse Neighbor Discovery / A. Conta
------------------------------------------

<draft-ietf-ion-ipv6-ind-03.txt>

Goal of presentation to make sure IPng is aware of this work. Would
like IPng to do a w.g. last call for Proposed Standard.

Inverse Neighbor Discovery - IND
- Extension to Neighbor Discovery - inverse discovery
o based on known link layer address - request destination IP address
- correspond to IPv4 Inverse ARP (RFC 2390)
o use the same type of messages as ND
o add new option - list of IP addresses
- Application
o Frame Relay Networks (or other links) - IPv6 similar for IPv4
Inverse ARP
- Status
o passed ION WG Last Call
o with feedback from the IESG:
- published new draft (draft-ietf-ion-ipv6-ind-03.txt)
o moved Frame Relay specifics info in Appendix section.
o aligned the IND option (List of IP addresses) with ND
options
o allow list of IP option in Solicitation
o remove use of O bit

Messages

- IND Solicitation
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-

IP Fields: Source Address, Destination Address, Hop Limit, Priority, Authentication Header

ICMP Fields: Type, Code, Checksum, Reserved, Required options: Source link-layer address, Target link-layer address
Optional:
Source IP Address List
MTU

IND Advertisement

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-

IP Fields: Source Address, Destination Address, Hop Limit, Priority,
Authentication Header

ICMP Fields: Type, Code, Checksum, Reserved, Required options:
Source link-layer address, Target link-layer address,
Target IP Address List
Optional:
MTU

IND options

The Target Address List option is a TLV (type, length, variable size
field) option, with the following fields:

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - +
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// //
+ IPv6 Address +
// //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// //
+ IPv6 Address +
// //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~
+-+-+-+-+...

Use in Frame Relay Networks

[figure]

ACTION: IPng document editor will start a two week working group last call of IPv6 Inverse Neighbor Discovery for Proposed Standard.

Local Scope IPv6 Networking / R. Hinden
[Talk not given, due to lack of time]

Slides

None received.