Subject: Draft IPng w.g. Minutes for November IETF

From: Bob Hinden <[email-masked]>
Date: Mon, 06 Dec 1999 17:41:17 -0800

Corrections/changes to me.

Thanks,
Bob

___________________________________________________________________

IPng Working Group Meeting Minutes
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 (5 min)
    Review Agenda / S. Deering (5 min)
    Document Status / R. Hinden (10 min)
    Summary of Tokyo Interim Meeting / S. Deering (10 min)
    IPv6 extensions to RPC / S. Majee (15 min)
    TAHI IPv6 Interoperability Test Report H. Miyata (10 min)
    IPv6 Socket Scrubber / C. Williams (10 min)
    IPng Statement on Privacy / S. Deering (5 min)
    Privacy Issues w/ Addrconf / Anonymous (20 min)
AGENDA ( THURSDAY, November 11, 1999)
    Wireless Telephony / C. Perkins (30)
    Connection/Link Status Investigation (CSI) / H. Kitamura (10 min)
    Unidirectional Link Routing / H. Afifi (5 min)
    Source Address Selection Draft (R. Draves) / S. Deering (30 min)
    Text Syntax for Scoped Addresses / T. Jinmei (15 min)
    IPv6 Inverse Neighbor Discovery / A. Conta  (10 min)	
    Local Scope IPv6 Networking / R. Hinden (15 min)

----------------------------
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 - Ignatius Souvatlos (?) 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

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, [email-masked], 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 [email-masked]

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
     o 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:
     o Extensions to Router Solicitation, Advertisement
     o Requiring DHCPv6 interactions
     o 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
     o CSI option
  - Three new ICMPv6 messages
     o Status Request / Status Reply
     o  Status Report

  [ example slides]

What's new
1. Simplify the CSI option header format
     o Page and Bitmap fields are deleted. (Alignment: 4n+2)
     o Record format in Data Space is changed
     o Mandatory component of each Record is introduced
2. Introduce two types of Operation Modes
     o SPSR (Single-Probe/Single-Reply) for normal environment
     o SPMR (Single-Probe/Multiple-Reply) for problematic environment.
3. Refine the method to specify Investigation Data Types
     o Hierarchical method is used to specify acquired data type.
     o Define the "Basic Investigation Definition Set"
     o Ideas of "Elementary Investigation Data Components" and
       "Combined Components Group" are introduced.
     o 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):
     o No complex and intelligent operations are required
     o Only simple data acquisition operations are required
     o 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:
     o Intelligent operations are required
        - to receive Status Reply and Report(s)
        - to analyze collected data
  - The CSI mechanism is simple enough and
     o easy to implement to any IPv6 nodes.
  - Intermediate nodes

Showed results of implementation

Conclusive Questions
  - Do you want to
     o investigate the "Incoming" path?
     o investigate by the efficient (minimum packets) method?
     o execute the "Record Route" operation of the path?
     o measure the consumed real-time bandwidth?
     o verify the status of the communication path?
  - Why not use the CSI mechanism?
     o 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
     o URL will be announced soon on ipng and on udlr mailing lists
       ([email-masked])

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
[email-masked]

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:
     o When application / upper-layer specifies.
     o When policy specifies.
     o When sending to that address.
     o 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
     o node-local, link-local, site-local, organization-local,
       global...
  - Scope identifier
     o a particular instance of a scope
     o "link identifier" will also be used as an identifier of a link-
       local scope
     o 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.
     o "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
     o 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
     o 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
     o Not a complete solution
     o you should still specify the ID when using a scope other than
       the default

Proposed Solution
  - Introduce a new format for scoped addresses:
     o <scoped_address><delimiter>< scope_id>
     o Example: fe80:: 1- 2
         scoped_address = "fe80::1"
         delimiter = "-"
         scope_id = "2"
     o Should be applied to both unicast and multicast
  - Extend library functions that translate between a hostname and a
    numeric address
     o takes a literal address in the extended format
     o returns a numeric address structure that contains the scope ID
     o Note: we don't recommend you to use any particular library
       functions

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

Implementation( 1) Address extension
  - KAME's extended format for scoped addresses
     o (currently) for link-local addresses only
     o interface name as link ID
        -  assuming 1to1 mapping between links and I/Fs
     o "@" as the delimiter
     o 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
     o kernel sends a packet to the link specified by sin6_scope_id
     o kernel sets a link ID of a received packet to sin6_scope_id
  - KAME's getaddrinfo supports the extended format
     o takes an address as a hostname in the extended format
     o sets the according scope ID to the sin6_scope_id field
  - getnameinfo is also extended
     o takes sockaddr_in6{}
     o returns a literal address in the extended format.

Implementation: How it works

  [example slide]

Examples
  - ping command
     o 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?
     o KAME's "@" seems not good
     o other candidates
       - <scope_id>/<address> (used in MSR)
       - <address>-<scope_id>
     o 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>?
     o is <scope_id> the most significant part?
     o if so, should it be placed before <address>?

Related (Open) Issues (2)
  - What is the desired identifier?
     o interface name
        - not so intuitive
        - (sometimes) even confusing; how to distinguish I/ F, link,
           site, ...
     o numerical identifiers
        - tend to change, not intuitive
     o 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
     o http://[ fec0::1234-bar. com]:80/index.html would be better than
     o 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]

--------------------
Meeting Adjourned
--------------------

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------