Last Modified: 2005-01-17
1. Administrivia, Chairs (5 mins)
1. Introduction, Chairs (5 mins)
2. shim6 solutions architecture overview, Geoff Huston
draft-huston-l3shim-arch-00.txt (15 mins)
3. review proposed charter, Chairs (25 mins)
3.1 General goals and scope
3.2 Specific deliverables and milestones
4. AOB, chairs (10 mins)
- Next steps
Proposed charter :
Site-multiHoming by IPv6 interMediation (shim6)
Description of Working Group:
The shim6 WG is to produce specifications for an IPv6 site-multihoming solution based on the architecture developed by the IETF multi6 WG. The multi6 WG was tasked with investigating solutions to the site multihoming problem that will allow the global routing system to scale. The outcome of the multi6 WG is a specific network-layer shim architecture for addressing and address handling of sites and nodes. This includes switching to different locator addresses when connectivity changes, but without the changes of address being visible to upper layers, which see a fixed Upper Layer Identifier address (ULID).
The shim6 WG is to complete this work with the required protocol developments and complete the architecture and security analysis of the required protocols.
The background documents to be considered by the WG include:
The input documents that the WG will use as the basis for its design are:
The shim6 WG is to publish, as standards track RFCs, specifications with enough details to allow fully interoperable implementations of the shim layer approach to multihoming as agreed on by the multi6 WG. These implementations will have the ability to take advantage of multihoming without adding to the growth of the global routing table by using aggregates already announced by upstream providers.
Since the solution requires state to be maintained at both ends of a communication, the protocol specification document needs to contain a state machine description.
Some state transitions may result from external events, however, such as failure detection rather than from protocol events. These should be documented in a separate document.
Multihoming is today also often used to achieve various other features, such as traffic-engineering. The Shim6 WG should document the use of the shim6 solution in these cases in an applicability document.
More work items and milestones might need to be added at a later date to complete all implementation details needed.
In addition to the basic network layer shim solution, the shim6 WG is specifically chartered to do work on
o Solutions for site exit router selection that works when each ISP uses ingress filtering, i.e. when the chosen site exit needs to be related to the source address chosen by the host. This solution should work whether or not the peer site supports the shim6 protocol.
o Solutions to establish new communications after an outage has occurred that does not requires shim support from the non-multihomed end of the communication. The wg will explore if such solutions are also useful when both ends support the shim.
o Congestion control and explore how this and other QoS and traffic engineering issues may interact with the use of multiple locators at both ends.
o The relationships between Upper Layer Identifiers (ULIDs) and Unique Local Addresses.
o ICMP error demuxing for locator failure discovery.
o If necessary, develop and specify formats and structure for
- Cryptographically protected locators
- Carrying the flow label across the shim layer defined in the multi6 architecture.
The WG will consider whether the proposed model is exposed to any security threats in addition to those documented in draft-ietf-multi6-multihoming-threats-03.txt. In any case, the specifications must specifically refer to all applicable threats and describe how they are handled, with the requirement being that the resulting solution not introduce any threats that make the security any less than in today's Internet.
The WG will not consider items outside the above scope, such as interaction with mobility, transport level solutions, or alternative identifier formats. However, the WG will consider developing methods for the shim6 level to handle transport layer events (or indicators) to the shim6 layer as in scope. These events will include any (if at all) interaction between the application layer and the shim6 layer as well as documenting what interaction is required between the transport and the application layer. How various transport layers such as SCTP and DCCP will handle a scenario with a shim6 layer under it is not in scope to start with, but should be addressed in a separate document later. Whether this is a topic for the shim6 WG or a transport area WG is left for a future IESG decision, once the shim6 solution has been more worked out.
MAY 05 First draft of architectural document
MAY 05 First draft of protocol document
MAY 05 First draft on cryptographic locators, if required
MAY 05 First draft on multihoming triggers description
MAY 05 First draft on applicability statement document
SEP 05 WG last-call on architectural document
SEP 05 WG last-call on applicability statement document
NOV 05 WG last-call on protocol document
NOV 05 WG last-call on cryptographic locators, if required
NOV 05 Submit completed architectural document to IESG
NOV 05 Submit applicability statement document to IESG
JAN 06 WG last-call on multihoming triggers description
JAN 06 Submit document on cryptographic locators to the IESG, if required
JAN 06 Submit protocol document to the IESG
MAR 06 Submit draft on multihoming triggers description to the IESG
First few minutes missed.
Kurtis: mention that this is a possibility, but moves on. The topic of unreachability needs more work.
Erik Nordmark- the documentation assumes all addresses are in the DNS; some work is needed there.
Aaron Falk- how much does this change existing apps?
Erik - some apps already do this, its depending upon APIs. If your application doesn't do the DNS, then this can be hidden from the apps. The open issue is how to speed this up. Are there other dimentions to the sensitivity to multiple transports?
Allison Makin - some SCTP services are partially reliable (for some length of time, for example) which the application layer is sensitive. Actually, that's a reliablity issue, not congestion control, sorry, its Friday. There are different congestion control mechanisms; each has different properties and different responses. Different bustyness, sending, etc. All of them have different dynamics, so that you can't simplify this to the lowest (or highest) common denominator.
Michael Tuexen: You can have different behavior per-packet in SCTP, which you can't see on the wire. We have some experience in SCTP, so you might want to review this. Multiple locator support may be dependent on the transport layer.
Allision - congestion control layer may need to be bound to the path. If the locator and the path are tied, then congestion is tied to the locator.
Erik: there is work needed to be done on how to run SCTP on top of shim6, for example. In the past, IPv6 stuff that looked good on paper didn't do so well in practice. Shouldn't we do some experimenting in a number of these "needs work" areas?
Agenda interupt: charter discussion
Review of the charter
Michael Tuexen: wants to make sure that dccp and sctp are not broken by shim6
Brian: debating charter wording re transport protocols
Kurt: thinks it may not be in the scope of the BOF/WG
Brian: "make sure you don't break any transports"
kurt: Shim6 does not intend to break ANY transport protocol
Pekka N: thinks there are deeper issues involved in the id/loc split, the charter should explicitly exclude things like multipath congestion control
Kurt: multi6 goals RFC3582 explicitly requires not breaking anything. So, we do not need to be reminded by everyone.
Avri: wants to know why mobility is excluded, as they share common problems
John Loughney: suggest documenting address interaction of shim6 with congestion control. Split discussion of congestion control, qos and TE
Michael: don't break sctp behavior.
Kurtis: we can't break any transport protocol.
Pekka Nikander: as this is an id/loc problem, we should only look at not breaking things. Studying interaction of congestion control and multihoming is a research topic, maybe we should handle it in a research group.
Kurtis: Do no harm is part of the consideration
Avri: Worried about the exclusion of multihoming & mobility. There are relationships between these. Thinks that this is important, but not taking into account mobility is a risk. We are trying to do a major change here, without taking mobility into consideration. Thinks the definition of site determines whether there are common issues between multihoming and mobility. Well, you know that some people would like to solve mobility again, and trying to find a place to do it in ...
Kurt: thinks any solution here will not break mobility
Brian: thinks the solution will NOT break MIP, but agrees with Avri that we might have a missed opportunity here.
Margaret Wasserman: Wants to state that there are no special efforts taken to enhance mobility, but they might be considered later
Avri: disagrees with Margaret and it might be too late to do something later. Mobility should be handled at the begining. Thinks not enough study has been done about the commonalities and thinks the wording for exclusion is too strong.
Erik: are multiple things we can do? Should this protocol subsume all that MIP does - that would be silly. Saying this protocol should work with dynamic locator sets is already addressed in Geoff's document. Someone should sit down and write an individual document on the intereactions and then we could consider.
Kurtis: we are trying to say that we don't want to go into saying what MIP may or may not do, what SCTP may or may not do.
Erik: having someone look into this would be a good thing.
Pekka: Supports that current text, there is a time-to-market issue with this, so we should restrict the scope.
Margaret: believes working groups do best if there there is a crisp scope. This area is extremely interesting, but we do need to solve multihoming in IPv6.
Kurtis: Say that other issues (mobility) could be handled by other groups and any requirements could be sent to shim6.
Margaret: doesn't think that needs to be put in the text. It is more about acheiving an reasonable ammount work.
Pekka: Mobility is a tricky thing, dynamic locators may or may not be the same thing as mobility. Using dynamic locators may have issues with security. If we are going to handle dynamic locators, that should be in the charter. Kurtis: Please send text.
Avi: would like to see mobility removed from 'out of scope' - multi6 did do some good analysis on this. Could a group be put together to consider this.
Kurtis: Let's discuss this with ADs. Pekka: Dynamic locator change is a tricky thing, because dynamic means different things to different people. We should be careful about this.
Scott: was reminded of 'we'll stick security on the end' and thinks that is not going to work.
Brian: chair hat off - there might be a way to use shim6 as a mobility solution, if done right, but the discussion is theoretical. margaret: doesn't think the exisiting work is not fully realized yet, we need to refine the design goals first. Other groups should be involved, but this group should be in charge of the multihoming design goals.
Aaron: wished he had a recording of Tim Sheppard's comment last night. Aaron would like to see running code. Maybe an analysis milestone is needed.
Jari Arkko: Charter should say that this should not break anyting. Add dynamic locator support, even highly dynamic, should be added to the charter.
Brian: had a voice saying 'renumbering' in his ear.
Tony Hain: The world will be a mobile environment, so this must work. This will do harm somewhere, so maybe minimizing the harm is important.
Brian: why? (a joke).
Tim Sheppard: not worried about Avi's worry; set of locators that you use change, it is just a matter a timescale. How do you cope with the changing is the important part.. It is probably good to go ahead with this as currently proposed. In 2 years, we will have alternatives then we can see where we stand. Having multiple alternatives is probably a good plan.
Brian: Hum if this is a good direction, with tweaking -> many hum if a bad direction -> none.
Margaret: (AD time). Questions to the room. How many will are on the list - many. How many have read the drafts - many. How many have employer support for this work - little less. Can we decide to form a working group? many. Not enough - a few. Should we form a wg? Many No working group? none.
Brian: minuted meeting is over.