Minutes IETF98: 6man
minutes-98-6man-01

6MAN Working Group - Chicago IETF Meeting
Thursday, 30 March 2017 9:00-12:30, Zurich D
Chairs: Bob Hinden, Ole Troan

Minute taker: George Michaelson
Jabber Scribe: Tim Chown

Jabber Room: 6man@jabber.ietf.org
Meetecho: https://www.meetecho.com/ietf98/6man

-----------------------------------------------------------------------
-----------------------------------------------------------------------

Agenda

Introduction, Agenda Bashing, Document Status, Chairs, 15 min.

Working Group Drafts
--------------------

IPv6 Specifications to Internet Standard - IETF Last Call Summary,
draft-ietf-6man-rfc2460bis , draft-ietf-6man-rfc1981bis ,
draft-ietf-6man-rfc4291bis , Suresh Krishnan / AD, 40 min.

Active Individual Drafts
--------------------

IPv6 Node Requirements, draft-clw-rfc6434-bis , Tim Chown, 15 min.

IPv6 Router Advertisement Prefix Information Option,
draft-pioxfolks-6man-pio-exclusive-bit , Erik Kline, 15 min.

Route Information Options in Redirect Messages,
draft-templin-6man-rio-redirect , Fred Templin, 10 min.

New Individual Drafts
--------------------

DoS signaling with Hop-By-Hop options,
draft-francois-dots-ipv6-signal-option , Jerome Francois, 10 min.

IPv6 Address Usage Recommendations,
draft-gont-6man-address-usage-recommendations , Christian Huitema, 10
min.

Recommendation on Temporary IPv6 Interface Identifiers,
draft-gont-6man-non-stable-iids , Christian Huitema, 10 min.

-----------------------------------------------------------------------
-----------------------------------------------------------------------

IPv6 Specifications to Internet Standard - IETF Last Call Summary,
draft-ietf-6man-rfc2460bis , draft-ietf-6man-rfc1981bis ,
draft-ietf-6man-rfc4291bis , Suresh Krishnan / AD, 40 min.
-----------------------------------------------------------------------

IETF Last Call Summary,

  https://www.ietf.org/proceedings/98/slides/slides-98-6man-ietf-last-call-summary-

  Suresh: All pretty contentious (alas)

  Five docs moving to Internet Standard, 3 updates, 2 elevation 'in place' (no
  changes)

<draft-ietf-6man-2460bis>

  Animated discussion, lots of input, AD thanks. constructive. No real
  dissent to the ban on EH insertion. Looking for closure.

  Brian Carpenter: What people do in their own networks is their own
  business. Leave the door open to safe EH insertion inside a private
  domain. We should be practical and realistic. Have text. Propose
  extending introduction to make it apply internet-wide. The most basic
  protocol of all (IP) should state, will take to list.

  Robert: insertion is ok. in my own DC, or provider inside. based on
  this, clearly stated in doc, forbidden. doc is 20y old

  Suresh: cannot do things about private domains like a DC we're not the
  protocol police. this is about interoperability. If do insertion,
  somebody needs to explain whats going in.

  Robert: feel this is inconstant.

  Stephano: Always see this on ML "use encap" wrong to put encap in
  front, or in place of EH. Not only IETF for e2e also defines for
  control., bandwidth, intra-domain. here in the same
  situation. publishing something we may need to amend soon. Since
  updating 20yo document, knowing there have been changes, lets take the
  opportunity to fix things.

  Suresh: have examples, bring them to the document.

  Lorenzo Colitti: Disinterested comment, support the position 100% that
  this can (and should) be changed. Publish, if we make sensible changes,
  then change, standardize, done. we do this all the time. this is just a
  reflection of whats been done since 20y its state-of-the-art.

  Ahmad: 20y can wait 3-4 weeks

  Suresh: unless planning for 3mo develop, then thats impeding

  Lorenzo: write what you want, evaluate, use, and if not appropriate,
  scope it. Advance the document.

  Michael Richardson: Like Brians proposed statement. Some words badly
  chosen, impede progress of the document because of the applicability to
  gov and other agencies. If we do publish still have 2y tail of
  testing. Regularly write docs which are internet protocol: specs, not
  just global connectivity Internet documents. Applaud, support.

  Ahmad: push to 'do something' very quickly even though we know changes
  coming. Doesn't make sense to push 2 weeks early just because we don't
  want to wait.

  Suresh: whats coming? the draft which is coming?

  Bob Hinden: this is not just a 2 week new draft its been worked on for years.

  Mark Townsley: its not on the telechat agenda for a couple of
  weeks. Suresh: do not want delay. Mark: floor is open for discussion.

  John Leddy: don't understand the impact of the language, to
  summarize. Vendors can implement insertion, Operatiors can implement
  inside their domains. Any WG/STD considering insertion.

  Suresh: 2460 goes through, then.. some other group can document this.

  John: so the impact is internal IETF process about how people can
  document this, align with the STD.

  John: what do we think this language is going to achieve as impact?

  Suresh: document discussed today, the WG consensus was "rough" -more
  than rough. Not clear-cut in the WG, and then changed in 2weeks. this
  is contentious for some time. Rough consensus, yes, but not just out of
  the blue.

  Mark: exactly. moving from 20y deeply questionable, now hitting IETF
  last call, and changes made by you, wen't from kind of iffy to -very
  clear SHALL NOT. That was a big change just a few weeks ago.

  Suresh: the WG did it Mark: the WG left it ambiguous.

  Bob Hinden: this is why we do IETF last call. Suresh's conclusion from
  this, is: make it non-ambiguous.

  Mark: IETF last call designed to get wider input, get other WG
  awareness not to make substantive change.

  Bob: its the AD's call thats why we have this process.

  Mark: same people, same discussions on IETF list as 6man list I dont
  think we learned anything more.

  Bob: but looking at other non-WG participant input, I think it was
  different and I support what Suresh concluded.

  Mark: back to my original statement. STD is a big deal, and should
  reflect solid consensus. This is not very solid in the community even
  if it was original intent of the AUTHORS.  20 of EH? no. not really
  deployed. Just getting into serious deployment. Leading operators of V6
  deployment say they want to do this not just inside their control
  domain, but need this to work globally. This stuff is coming. change
  text before IETF last call.. maybe we didn't need to

  Lorenzo: can't process it without understanding it.

  Suresh: requires clear production to do this.

  Mark: I am hearing 'easy to update this document' Don't have confidence
  won't hear 'can't do that its STD'

  Suresh: bad argument, if I abandon, the same people are going to still
  say 'cant do this' no matter what. Goal is to remove ambiguity. This is
  my call. I am overriding the people who are in the rough. I unhappy
  take it into Appeal. I see clear consensus but its open to appeal.

  Lorenzo: post to list said send comments: this is it, if you don't like
  it, there is an appeal?

  Suresh: not hearing arguments to change my mind.

  Ole: need to move on. Mark: my reasons are on the ML

  Tim: I see the same consensus, I like Brians wordings, they open the
  door to another document in early draft, clarify why not doing encap,
  and how to do safely. It wont pass in weeks, will take years. my view
  is publish as described with Brians rev, come into WG and work
  through. Quite likely if worried 'cast in stone' there will be another
  change.

  Suresh: will not use text on here to block things in the future. If
  documented breakage emerges we will take that in hand. we do updates
  all the time. Find argument not productive

  Lorenzo: earlier point good, have useful things relying on header
  insertion. What we say here, is baseline for entire internet need
  higher bar. SR for instance, clarifying the specs, doesn't mean we cant
  do SR tomorrow. address interoperability issues, in the control led domain,
  evaluate risks, mitigate, as opposed to leaving the door open to use in
  the wide, break in the wide. Don't understand the problem with the
  text. Cannot insert EH without processing it. write things up.

  John Brozowski: not here to argue with it, even division of views, Q,
  directed at AD. overwrote using your own words, so on what information?

  Suresh: nobody complained about underlying issue, clarifying text on
  that basis, for intent always there. WG consensus was iffy but the
  survey, Ole/Bob did, people were ok with it, ranking different, but
  nobody objected strongly?  Adding won't break anything. This is how I
  see consensus happening. I am listening for why the consensus is wrong
  because breaks, concrete thing, sustainable from 2460 but not this
  -bis, then I know my technical decision is wrong.

  John: My view of your responsibly is big decision, controversial, so
  your job is "do homework" and "talk to people" need to be seen to talk,
  not happening, thats a problem. as operator, where is the conversation?
  spoken to them?

  Suresh: no, not yet.

  Christian Huitema: listening to the debate disappointed. See
  purity/practicality debate (channeling RB) reason its not deployed is
  not 'lack of purity' I don't care personally, but the process, needs to
  respect operational views.

  Nalini: push back on a couple of things Lorenzo said, but agree on
  others. People in the room, lot in the room not deployed. Talk to large
  enterprise fortune 500 and others, every day, and they have not, not
  deployed IPv6, not explored, may be doing edge translation, tell me
  IPv6 is deployed, to extend we like? no. Personal opinion EH are
  wonderful, biggest reasons to deploy IPv6, capability to do extensions,
  to do things, whats keeping it alive, reason to deploy for many of
  them. Sure, ISPs have it, wonderful, but enterprise banks insurance, to
  deploy, hasn't happened. Huge number of cycles in this argument can't
  keep up. lot of repeating. Lets move on. go ahead, revise. living
  document.

  Jinmei: like to add, argument to who is deploying EH. should also be
  careful about reliance on EH interpretation DNS servers assume IPv6
  packet min MTU will not be blocked.  in this case we don't use an EH
  but rely on the widely believed restriction that EH is not inserted in
  the middle of the network. Think this point is equally
  important. Support addition, Brian Carpenter clarification.

  Ron Bonica: Observation: reason arguing because half people in the room
  afraid if standardized, then impossible to do SRV6 draft because
  constrained. may be justified. Proposal. perhaps thing to do, go into
  room, with Stephano and come out with text to add to SRV6 to make legal
  even if this text standardized, then issue goes away. Willing to try?

  Jen Linkova: lot of routers in internet, already violate EH and process
  in ACL border router, what are we going to do.

  Suresh: very clear we can't constrain,

  Mark: this standard should reflect reality, the reality is ACLs
  process, spirit of text codify original wishes of 2460 authors, not
  enough of communication to operators. hearing this 'we are processing'
  then how can it be in a document if reality on the wire is violating
  it.

  Fernando Gont: don't understand why having it again. IETF LC in WG,
  outcome of conversation. still discussing, something we decided. dont
  understand why. even in the context of document published 2-3 days ago
  for last call finished while ago dont understand

<draft-ietf-6man-4291bis>

  Suresh: got lots of operation text suggestions. two sides so far apart,
  cannot get text to satisfy the whole. Do not see consensus to move
  forward sending back to WG.

  Lorenzo: think process serves us well here, because if we can't do it,
  then have to do this. Agree strong divide. two camps. Should take a
  step back, in WG think about what we lose by having this fixed
  boundary. Look at arguments applying to V6 specifically, not learned
  from V4. dynamics of addressing are clear. 64 bits to 24 bits are huge,
  not just the apparent 40 bit gap. lets come up with something more
  encompassing, find out what we want to change. Have to do in the
  WG. Word smithing this text is trying to change implementation not
  re-design. but we have to re-design. Look to use cases. Tried to push
  what we cannot do with 64 which we can do with 128. Once we have those
  in mind know what to change. wont get that from word smithing on this
  document.

  Randy Bush: 64 is a magic number from IEEE MAC and worked until
  privacy. we don't need any boundaries. To clear misconception, use
  SLAAC all the time, think its fine. I wanted 56 but 64 is fine. RA is
  fine on SLAAC_RA side. DHCPv6 is fine, with router option, want to make
  it so customer has choice can do what they want to do. MUST language to
  run network doesn't help V6 but it helps NAT/CGN

  Pierre Pfister : text not in agreement, reason is because brought up in
  v6ops yesterday depends on use cases. way out, explicitly say the
  differences between different deployments

  Matt Mathis: this issue, previous issue is about tussle/paradigm
  gap. precedent, lays out both ideas, terminology, but need of MUST and
  MUST NOT for each side, both exist in the internet doesn't matter,
  decided in the marketplace. document both correct answers and have
  decision made in deployment

  Lorenzo: dont think we should think about this here, write use cases as
  Pierre said. Good outcome, time to consider the use cases. Randy has a
  point, Customers do what they want but we are responsible for what happens
  20 year off. we're going to live with this for 3-4 decades, design for
  the long term. have to think about what happens in the future. Take the
  time. use cases.

  James Woodyatt: Google draft of subnet and on-net prefixes, commend the
  draft. distinction is important, existing draft not making the
  improvement I'd like to see the confusion between subnet prefix and
  on-net prefix. to repeat, important. on-link are a routing proto
  discovery. can use link or have to ask. subnet is address alloc for a
  host. think set at 64 because SLAAC rather not think about hosts doing
  other things, bound to SLAAC but people on other side, no doesn't matter
  what host addr config is done, 64bit IID is separate on-link prefix
  send to router or use ND. thats the basic confusion. still see present
  in current draft, long draft liberal/conservative to upgrade text. some
  bits the same for both options could be added, could improve I would
  support.

  Michael: echo James.  all use tenbase2? use real switches? I dont think
  so. there IS a switch in the middle. has discovery and trace. the
  on-link stuff should die, layer 3 router is it. lets be clear, the
  layer 2 thing. networks break. thats not being on-link on-link is
  important.

  Bob: good topic to discuss. Lots of time to talk about it.

<draft-ietf-6man-1981bis>

  Suresh: ongoing looking for text to revise, not break existing
  Implementors. haven't made a call yet. looking promising, yet to be seen.

  Bob: text coming, waiting to hear from reviewers will elicit draft. I
  think big improvement, old versions, TCP stuff, does it without
  changing proto. have to decide if IS or proposed standard.

  Suresh: thats the issue

  Francis Dupont: <inaudible>

  Suresh: next steps: telechat will put up, still open to hear from
  people. if wrong explain WHY: feel free to talk.  Other two docs had
  no discussion, going to telechat.

IPv6 Node Requirements, draft-clw-rfc6434-bis , Tim Chown, 15 min.
-------------------------------------------------------------------

  https://www.ietf.org/proceedings/98/slides/slides-98-6man-rfc6434-bis-ipv6-node-requirements-update-00.pdf

  Tim Winters: Node requirements update.

  some question for the working group.

  Calls for uplift of SHOULD to MUST fior DNS resolver carriage. NO
  OBJECTS FROM THE FLOOR,

  one +1: MLDv1 MUST and MLDv2 SHOULD.

  Dave Thaler: use case for constrained devices conformance, avoid
  implement cost in memory of MUST for not-needed. can argue some fixed
  function device to get job done must use MLD then ok, but if not, then
  NO not normative needed.

  Tim: bad implications things done to network, logic is dont do ND right
  in trouble

  Tim Chown: pit into document, general nodes, constrained nodes, can do
  weasel words to consider in device but doc is general node devices
  doc.

  Brian: been sending ff02::114 want them to arrive. some nets they don't
  arrive, because MLDv2 not supported. want MUST because I think new
  multicast solutions demand it

  Dave: fine explain put in doc. don't remember how normative in
  doc.

  Tim: there is MLDv2 lightweight, addresses this (not multicast)

  Dave: to scale to IoT.

  Ali?: wrt list of items proto removed, mobile IPv6 removed based on
  comments.

  Tim: asked if impl, not general. saw comment. not a whole lot of
  interest. if deployed will put back in,

  Ali: open source impl has been taken up to be maintained, 1y dead but
  now taken over and active. worth being aware.,

  Tim: take to list

  Tim Chown: back in another doc

  ???: Also want Tim: will put back in

  Path-MTU. PLPMTUD support. put SHOULD Language. 1981 fall off the plate.

  Matt??: <inaudible> not sure supported in constrained
  implementations. Frag in constraint is dicey.

  Tim: can cover in doc

  Brian: difficulty 1) 1981 does work on many many paths, do not think
  should downgrade 2) 4821 is underspecified document. nonspecific
  language. not sure why on STDs track. needs update. SHOULD is ok but
  its meaningless no guidance what to do. 1981 remain mandatory until
  4821 accurate

  Ole: think this is valid

  Francis: keep 1981 as SHOULD

  Dave: this not internet requirements this is node requirements. across
  LAN, switches can send stuff. backwards compatible &c need 1981 as
  SHOULD, requirements so can not do the SHOULD, pref is add 4821 as
  SHOULD keep 1981 as SHOULD for this iteration.

  Tim: need parts of 1981

  Bob: repeats 1981 language referring to minimal impl.

  DHCP-PD for hosts.

  Francis: two comments, ppl who dont read reference RFC. uncommon term
  of art confused with DHC WG. session today details to change, because
  of new use of Prefix Delegation. some impl, strictly enforce 64
  limit. maybe needs to be relaxed

  Lorenzo: we considered implementing, asked operators 'going to support'
  but the answer was .. not really. not aware of any. can't typically
  connect device which supports PD. typically has DSL or coax, not host
  friendly. do PD by default on a home network. 12 devices doing PD run
  out of /60. so not sure how practical. few nets support, ones which do
  can do damage. premature. want to support PD, ask carrier mobiles and
  tether, they say no.

  Ole: agree Lorenzo, it is premature. Have three different mechanisms if
  PD must be a router. So seems not host aligned.

  Alexander: consider yes, bit more time. distinction between host/router
  is a fine distinction difficult to make.

  Tim: say node requirements to try and stay away from that.

  Eric: not a WG item so can't second Q to

  Chairs: how much time

  Because Q about doc but not related to slides

  Ole: fit at end

  Fred: use PD inside corp net for airplanes and related systems.

  Dave: doc should NOT talk about PD. in favor of PD, but not in NODE
  requirements documents. wrong document.

  MIBS update to YANG.

  No major requirements keep aligned to Router Req doc

  Privacy Addressing.

  Add SHOULD to 7844 privacy profiles

  Dave: support for MUST if support privacy addresses. if impl.

  Bernie: profiles issue. maybe point to it, say IF device may be mobile,
  privacy is considered strongly

  Lorenzo: think say devies which identify Users, mobile devices,
  pervasive monitoring suggests should be doing but dont know if
  consensus MUST can we do that?  on by default? hearing

  Dave: yes cant do it constrained

  Tim: add section to doc

  Lorenzo: gen purpose device?

  Tim: take back to list

  Lorenzo: 7844 discourages stageful DHCPv6.

  Cary: text should be configurable to privacy drafts. might want to get
  into fine detail or point to other document

  Tim: agree not in this draft point and say read Dave

  Apple: MUST be configurable explain

  Tim: must be able to turn off and on in original draft. Answer may be
  not to say anything

  James: MUST be configurable by WHOM?

  Tim: read draft

  James: text not clear does it satisfy requirements for Manufacturer choses on
  or off, owner does not?

  Tim: let me take a look.

  DHCP vs RA for host config.. "here be dragons"

  Eric: 8028 mh behavior on list (Brian)

  tim: yes next version to include text Inform or BCP?

  Lorenzo: have to remove dragons if BCP.  either deal or go silent.

  Lorenzo: speculative

  Tim: good feedback.  Tim Chown: if/when adopted, discuss BCP status

  Ole: Hum for adoption strong in-room to adopt.  Chairs will confirm on
  the mailing list.

IPv6 Router Advertisement Prefix Information Option,
draft-pioxfolks-6man-pio-exclusive-bit , Erik Kline, 15 min.
-----------------------------------------------------------------------------------------------------------------

  https://www.ietf.org/proceedings/98/slides/slides-98-6man-pio-exclusive-flag-00.pdf

  Eric Kline: Apologies for -02 during meeting. some unfixed items from
  Seoul.  Motivations, every host gets /64, separated layer2
  domains. being talked in V6ops. nice as client to know. understood in
  3GPP arch, nice to know explicitly. simple bitflag to signal own the
  net. If unrecognized hosts do DAD and are fine.  Simplified from seoul
  was too clever, became 'brittle'. updated flag location to avoid flag
  bit collision added text because r flag mutually exclusive.  Continues
  with slides from Seoul so jump to end. interest in WG

  Eric: would the X flag be useful on 3GPP? don't think harmful but not
  useful if node knows on that model. intervening device, one hop away,
  bridge, then useful

  yes. ???: assumption node knows link model based on

  Eric: 7066 does the same thing, link model not implicitly segmented/L2
  separated

  Alexander: related to earlier discussion creating new dragon?  helps or
  not helps PD?

  Eric: perhaps. but, useful.

  Alexander: backwards compatible..

  Eric: not mutually exclusive. no way to say eg attach to /64 find out f
  PD possible, then do link number afterward. can be unnumbered, numbered
  without PD, or numbered without PD. (unnumbered links)

  Ole: have use cases. draft enforce

  Alexander: earlier drafts proposed to do PD by router advs. there are
  two drafts doing same functionality.

  Eric: draft in archive? expired?

  Alexander: can resurrect?

  Eric: discuss with ops. can point.

  alexander: will send again

  Lorenzo: support. links where device gets RA, knows from technology
  exclusive use, but nice to signal, avoid baking to link layer. useful
  to signal in v6. definitely useful in other link layers take this
  model. To Alex's point using PD have to provision separate
  networks. need R bit on for anything to work at all so now have to
  configure two things. with X bit can benefit from it, if
  understand.

  Dave (Apple): like this. one bit gets all the info. love. want
  discussed in WG.

  Fernando: concern duplicating functionality in DHCPv6 in RA and
  vice-versa not surprised if we wind up in scenario where support this
  option but not in PD and this is a bad call. duplicate everything not
  good. have to do both in both impl. take step back figure out whats
  best option to do. Looks similar to stuff we already have.

  Eric: not mutually exclusive. this is not about PD. being informed its
  yours.

  Jeffry Handal: To understand. client isolation, could permit battery
  conservation, energy efficiency because know don't do stuff.

  Mark: say 'way to get single prefix' maybe rather than

  Ole: take to list.

  Fred: router has to know host is authorized.

Route Information Options in Redirect Messages,
draft-templin-6man-rio-redirect , Fred Templin, 10 min.
---------------------------------------------------------------------------------

  https://www.ietf.org/proceedings/98/slides/slides-98-6man-route-information
  -options-in-redirect-messages-02.pdf

  Fred Templin: adding new host type to existing 3 types from 4191. type
  'D' like C but process redirects Eric: could the target send its own RA
  with lifetime zero, RIO in this scenario?

  Fred: wont accept unless first hop from prefix (router) second thing,
  RA-guard on link would discard.

  Dave: similar confusion. wonder attack possibilities, target is
  authoritative router. secure RA, but thing labelled router is not
  authoritative, so misled.

  Lorenzo: I am the router, I have PD from upstream, delegate the /64 to
  target, know not routable how delete?

  Fred: target gets delegation lifetime valid.

  Lorenzo: renumber, has implications. has to be
  communicated. unsolicited lifetime zero upstream, how to inform
  child. no way to tell.

  James: in this draft say type D can process redirects. does not mean
  they stop processing RA. eg RIO lifetime zero entire prefix.

  Lorenzo: semantics of RIO somebody else can claim immediately (lie) and
  you've been hacked.

  Bob: out of time

  Pierre: interested. disabled in Linux by default is security. think
  wrong argument, but thats what linux decided. maybe addressed in
  this. so interested. second avoids too much stuff in the RA. put in
  document redirect only for src address in packet 'D' host is not the
  right way to do it. don't need to be type C host to be type D host.
  Eric

  Vyncke: target sending RA w/RIO ignored by src what would RIO in
  redirect be accepted

  Fred: send these rate limited not every message

  Erik: but why ever process/send?  Jeffry Handal

  Cisco:* context changing, interesting ad-hoc networks, router and host
  at the same time, figure out how to do it. like v6 to be part of it.

  Fred: no, multicasting scenario eg like sat links

  Lorenzo: turning on RIO in android

  Alexander: answer to earlier not target sending RA, target is mobile dev
  do not send. dont do this

  James: concern to join draft, support. if not passed home gateways may
  do redirects per host address. 1000 behind target, home gateway may
  have to do this fill cache with individ.

DoS signaling with Hop-By-Hop options,
draft-francois-dots-ipv6-signal-option , Jerome Francois, 10 min.
-----------------------------------------------------------------

  https://www.ietf.org/proceedings/98/slides/slides-98-6man-ipv6-dots-signal-option-00.pdf

  Jerome Francois: presented in DOTS WG (see pack)

  Chris Morrow: google - please don't do this. many bad dimensions

  Jinmei: terminology is confusing. didn't understand "embed" actually
  means "insert". whether insertion is good or bad, need to be more clear
  about terminology.

IPv6 Address Usage Recommendations,
draft-gont-6man-address-usage-recommendations , Christian Huitema, 10
min.
-------------------------------------------------------------------------

  https://www.ietf.org/proceedings/98/slides/slides-98-6man-address-usage-recommendations-00.pdf

  Christian Huitema: Implications of the socket bind() on INADDR_ANY and
  leakage of temporary addresses, seen and reachable.  can do enumerated
  bind, but its a pain. don't do that. requires update on change
  Francis: UDP has some specific bind requirements in some
  applications/protocols stable vs temporary addresses

  Dave: useful to document the issues on the alternatives slide, three
  categories, generalize one bind India. sockets.  Stack layer sockets
  methods, firewall does it worth documenting techniques available,
  future work PS

  Michael Richardson: whats the alternatives to bind() is this what you
  are thinking about. something different to :: in there? scoping?
  flags?  not :: but something else? is that it?

  Christian: one possibility yes

  Michael: so API critical change Very supportive. useful.  Eric: reuse
  addresses, use cases are interesting. follow DNM work to get on-demand
  addresses and prefixes with different qualities. availability of types
  of addresses and prefixes. ability to bind to the prefix.

  ???: DNM is not here. mobility and non-mobility.

  Chris Morrow: problem exists in v4 basic security problem. maybe need
  language in draft.  Christian: practice of scope is much more a v6
  thing

  Chris: lots of machines with v4 many addresses

  Fernando: considering SOCKOPT to allow app programmer to specify
  properties, stable, local or whatever. comment chris made think theory
  in v4, but in v6 have the scopes problem ore evident.

  Ted: good work important problem API suggestion is good document
  defaults app developers will be flummoxed

  Jinmei: bind socket to ANY, even with filtering, packet delivered to
  the node, transport layer may reach TCP reset state or ICMP port
  unreachable some issues may still remain. easy to address.

  Christian: send text

Recommendation on Temporary IPv6 Interface Identifiers,
draft-gont-6man-non-stable-iids , Christian Huitema, 10 min.
--------------------------------------------------------------------

  https://www.ietf.org/proceedings/98/slides/slides-98-6man-temporary-ipv6-interface-iid-00.pdf

  Christian Huitema:

  More complex than original IID work. cookies, structure, avoiding
  correlations, lifetime binding to privacy events ???:* can cover in
  one document

  Ole: we're out of time, See you in Prague.

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