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
[Invest. Class] defines the meanings of [Invest. Type]
[Invest. Type] matches with Investigation scenarios
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: 
fe80:: 1- 2
scoped_address = "fe80::1"
delimiter = "-"
scope_id = "2"
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]