[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
SHIM6 WG notes from IETF 65
Hi,
heres the notes taken by Nevil Brownlee of the SHIM6 meeting - I'll make
these the minutes if there are no objections...
thanks to Nevil for this
regards,
Geoff
==============
Site Multihoming by IPv6 Intermediation WG (SHIM6)
Monday, March 20, 2006
1740-1840 Afternoon Session III
1850-1950 Afternoon Session IV
===============================
CHAIRS: Geoff Huston <gih@apnic.net>
Kurtis Lindqvist <kurtis@kurtis.pp.se>
AGENDA
1. Agenda Bashing, Victimization of scribe
[5 minutes]
The agenda is broken into 2 sections. Agenda items 2 - 6 address
topics related to the current set of drafts and necessary steps to
progress these documents through the WG. Agenda items 7 - 9 are a
followup to the current consideration of (loosely phrased) "TE"
considerations for possible extensions to Shim6 framework, and the
related aspect of re-chartering this WG to study this topic.
2. Review of Document Status and WG Roadmap
Chairs
The question to the working group is whether to adopt
draft-huitema-shim6-ingress-filtering-00 as a WG document
[5 minutes]
noone has read this document
** to the mailing list!
3. Review of Shim6 Protocol Specification
draft-ietf-shim6-proto-03.txt (-04 to be submitted)
Erik Nordmark
The question to the working group following a review of the
document updates is whether the WG is ready for a WG Last Call on
this document. [15 minutes]
4. Review of Shim6 Failure Detection Specification
draft-ietf-shim6-failure-detection-03.txt
Jari Arkko
Illitsch vav Beijnum
The question to the working group following a review of the
document updates is whether the WG is ready for a WG Last Call on
this document. [10 minutes]
5. Privacy Analysis for the SHIM6 protocol
draft-bagnulo-shim6-privacy-00
Marcelo Bagnulo
Do the privacy issues identified in the draft need to be
addressed? i.e. do we need to define some extensions to address
the privacy concerns identified in the draft? [15 minutes]
6. Default Address Selection in RFC3484
draft-arifumi-ipv6-policy-dist-00.txt
draft-fujisaki-dhc-addr-select-opt-01.txt
Arifumi Matsumoto
This draft raises some issues about default address selection of
RFC 3484 and proposes some solutions towards them. (This is an
informational briefing to the WG.) [10 minutes]
7. Report on IAB BOFs on multi-homing
Dave Meyer
[10 minutes]
8. Extended Shim6 Design for ID/loc split and
Traffic Engineering
draft-nordmark-shim6-esd-00.txt
Erik Nordmark
[35 minutes]
9. WG Discussion on Re-Chartering
Chairs
[15 minutes]
Recommended Reading:
a) active wg documents to be discussed at the meeting
draft-ietf-shim6-proto-03
draft-ietf-shim6-failure-detection-03
b) other documents whose status will be considered
draft-huitema-shim6-ingress-filtering-00.txt
draft-bagnulo-shim6-privacy-00
draft-arifumi-ipv6-policy-dist-00.txt
draft-fujisaki-dhc-addr-select-opt-01.txt
draft-nordmark-shim6-esd-00a.txt
c) other shim6 documents that may be referred to
draft-ietf-shim6-arch-00.txt
draft-iietf-shim6-applicability-00.txt
draft-ietf-shim6-applicability-00.txt
NOTES
=====
Notes by Nevil Brownlee
Intro by Kurt
Agenda bashing by Geoff
Overview: Doc Status, Road Map:
3 core docs, IP-stack-centric view of shim6
one i-d with ADs, waiting on other two.
What do we need to do to complete these base specs?
IAB BOF report on multihoming; site-based policies, TE
shim6 may want to know details of transport(s)
WG next steps
Ingress filtering draft (Christian Huitema). Should that be a WG doc?
It is part of the wg charter.
No-one has read it.
Take to mailing list.
Part I:
Erik Nordmark: Core Spec draft, -04 changes
03 to 04. Mainly editorial.
no IPv6 NATs now an explicit assumption.
text ordering reworked
Locator pereference options: requirement that any with element length >3
must have flags, priority, ..
retrans rules for I2bis (ocpied from I2 rules)
fixed security hole where single message could cause CT (peer) to be
updated. Now require a 3way handshake.
Context Recovery
02 to 03
Context recovery redone
expanded context tag, 32 to 47 bits
specified how context recovery and forked contexts work together
picked initial retransmit times fir I1 and I2, 4s. binary exp backoff.
Require R1/R2bus verifiers be usable for some minimum time, initiator
knows how long it is safe to retransmit I2 before going back to sending
I1.
Message type codes 0-63 don't generate R1bis messsages, 64-127 will
lots of editorial changes
Is it now ready for last call?
Comments:
Jim Bound: very political. Thinks its OK, but we (or someone)
should look at other options.
Geoff response - shim6 follows multi6, it's not the only way.
Jim: this is a lot of work to implement, could break things,
doesn't see customer pressure for it.
Geoff: Erik isn't saying "put it into production s/w" The WG question is
"is this draft ready for last call?"
Jim: Yes. Architecturally its a good thing.
Thomas Narten: not trying to push shim6 as 'the' approach. Who do we
want to implement this?
Geoff: WIDE Kame project is one example. But not ready yet for
companies to cimmit to making production code.
Thomas: Expermental? Plus app stmt saying "will eventually hit
standards track" Goal is to have it production-ready in, say,
2 years?
Dave Thaler: what's relationship betw shim6 / mobileIP6 / hip ?
supports 'experimental'
Jari Akko: need to look at this
Dave: want community consensus on relationship between these.
Should people implement all three?
Kurt: chairs/ADs should try to make a doc on this. Dave will
co-author.
Brian Carpenter: reminder about *proposed* standards
Marcelo Bagnulo: mobileIP and HIP interactions. What do you want to do?
why would you use shim and hip together?
Dave: want to know which scenarious are likely
Jari: need to know how this works with exising stuff, not neccessary
with new
Margaret Waserman: Have a stack doing shim6, need to understand its
interactions with others. Which one turns off what??
Group is chartered to make a stds track doc, and started with 32
variations!
Pekka Nikkander: draft on hip and mobileip exists
pkt formagt for shim6 and hip is roughly the same, could implement
them in same s/w module.
Erik: can you run them on the same host? Yes.
Are there cases when you need to use both together??
Charter addresses optimisations. Doc handwaves on this.
Jari Arko: Exploration
redesign of exploration protocol
-03 being considered for last call
issues: termination states, needs more detail
Erik: it doesn't, by itself, terminate
Have exp terminate at time we throw away the context;
fate sharing makes things simpler
Timers:
Erik: comparison with TCP timer settings. Don't know whether
probe packets will work, be aggressive, but not too aggressive
Geoff: what is sensible limit to exponential backoff?
Deprecated addresses (Marcelo)
draft recoimmends moving away from deprecated addresses.
Need to update the draft, and get more reviews
John Loughney: has read draft, will senmd comments
Geoff: will proceed to WG Last Call after next rev
Marcelo: Privacy Analysis
Scenarios
ULID-pair conext, estab exchange
Packets with the payload header
Update messages
keepalive & probe msgs
Draft doesn;t go into solution space
Do we care about privacy?
Erik: haven't written down: be careful with rfc 3041 temprary addresses,
etc. Need to write these down. Hiding doesn;t seem to achieve much.
Dave: never combine temp and non-temp address, 3041bis ??
?: 3041bis currently stalled
Geoff: does anyone think that this should be part of the shim6
applicability doc? Agreed to fold that into the applicability doc.
Extensions to 3484 are currently with ADs rather than this WG.
They will decide what to do about further updates/revisions.
Arifumi Matsumoto: 3484 & shim
initial contact must succeed if we use deferred shim context setup.
if dest host isn't shim-enabled, you can;t reach it!
initial contact failure reasons
"you can't implement a large SO with ULA"
Address selection policy forinitial contact
Redundancy for initial contact - an app should cycle dst & src
TE for initial contact
3484 is useable, not enough for redundancy and TE
No discussion
Dave Meyer
Notes from Operator Workshops
NANOG35 end-system complexity, DNS latency, inbound TE
current multihoming is site based, not host based. This is a big
change.
hosts and routers may not be managed by same group of people
IPv6 routing and addressing architectures
still an open problem
APRICOT06
Will continue the series, RIPE 52 in Turkey
Scot Lybrand: present this at NANOG? yes
Jim Bound: This is good, want to see more.
need to get managters along to those meetings too!
?: go one-by-one to operators.
Part II:
Erik: Is shim6 a brick wall, or part of an interesting architecture?
What's missing? We need to determine whether shin6 could reduce
pressure for IPv6 PI space
ID-locator separation
Unreachable ULID format - only know how to do scalable lookups
from a hierarchically allocated 'name'
Could do lookups in DNS (as an example)
ULIDs could be in a reverse lookup, e.g. ip6.arpa
get back SRV records
Traffic Engineering
Static and Dynamic TE
Locator rewriting by routers
Jim Bound: Hasn't read draft yet, but - CGA isn't happening in the
market, it has IPR problems, it breaks IPsec, ...
Erik agrees it could break e2e encryption. Receiver will see
the IPv6 packet.
Jim understands
Leslie: if path changes, might inject different addresses -
will shim6 switch back? would end nodes have to know what the
routers would inject?? No, user app would never see the shim6
addresses
IPv4 addresses as locators
Conclusion: non-routabloe ULIDs doesn't place any new reqs on shim6
mechanism. If we want to use router rewriting, define it now.
Dave: remarks about hip and CGA. hip has many of the same issues.
(lots of) convergence is good.
Jim: Now wants to go to Last Call for shim6.
Maybe we should just use identifiers (rather than addresses)?
That would make shim same as hip.
Erik likes having both adress-based and identity-based (?) IDs
Geoff: recycling names is expensive, uniqueness is not cheap.
Pekka: IPv4 - was IPv4 a header extension?
Erik: not decided, no work done yet.
Tom Henderson: hip research group has looked at what happens if
you use non-routable identifiers. Ongoing.
Geoff: we will explore these extensions Erik talked about.
Request WG to start writing some drafts about an API.