IETF71 March 10, 2008
Geoff Huston
Kurtis Lindqvist
Marcelo Bagnulo
Administrivia
Summary of current WG Document status - Kurtis Lindqvist
ESD - Erik Nordmark
draft-nordmark-shim6-esd-01.txt
Proxy Shim6 - Marcelo Bagnulo
draft-bagnulo-pshim6-02.txt
Simplifying Proxy Shim6 - Christian Vogt
Path Selection - Olivier Bonaventure & Luigi Iannone
draft-bonaventure-informed-path-selection-00.txt
draft-saucez-idips-00.txt
Next Steps Work Items - Iljitsch van Beijnum
The working group noted the current status of the 'base' protocol specification documents that have been submitted to the IESG for publication as Proposed Standard RFCs
The Working Group was presented with a number of approaches to extending the SHIM6 approach to encompass further refinements including the capability to express site-wide path preferences and the use of proxy agents to augment or replace host support of SHIM6. To start working on any of these extensions the WG will need to define the scope of the work as part of a re-chartering effort.
Administrivia
Agenda accepted without changes
Summary of current WG Document status - Kurtis Lindqvist
The Hash-Based Addresses draft (draft-ietf-shim6-hba-05.txt) is in the RFC Editor Queue awaiting the completion of the protocol specification draft to resolve a normative reference
The Failure Detection draft (draft-ietf-shim6-failure-detection-11.txt) is still in IESG review. DISCUSSes on IPsec, "valid lifetime" of RFC4861, the interaction between SHIM6 and Firewalls, and operational pair probing techniques noted as "MAY" are not fully specified, probing algorithm to be more precise, and keepalive intervals are not specified.
Jari Arkko noted that version 11 of the draft has cleared the majority of these issues. Remaining IESG DISCUSSes are consideration as to why BFD is not used for SHIM6, and resolution of Transport AD DISCUSS considerations on timers that have been addressed in the -11 version of this document.
ACTION: Jari Arkko: to look at the possibility to extend REAP keepalive parts with BFD packets, in the context of possible extensions of SHIM-6, and document the potential benefits and issues of using BFD for SHIM6.
The Protocol Specification draft (draft-ietf-shim6-proto-10.txt) has outstanding DISCUSSes on TE control model, interaction with the IPSEC processing model as described in RFC4301, and Experimental vs Proposed Standard. Jari Arkko has requested the Ads to document the reasons for Experimental publication, and is awaiting a report from Dave Ward on this. On the interaction between IPSEC and SHIM6 Illjitsch has drafted text for inclusion into the REAP protocol. Erik Nordmark noted that there is has been additional test in the protocol specification about layering with IPsec and shim6 in different ordering. The ICMP issue needs further review to ensure that ICMP processing behaviour is consistent in that ICMP messages that report problems that can be solved by shim6 are not passed to the uppler level protocol.
The Working Group is continuing work with the applicability draft, the locator pair selection draft and the API draft.
ESD - Erik Nordmark
This draft was written a couple of years ago. It was noted that discussion about proxies can benefit from these ideas. There are three concepts in this draft:
With respect to unreachable ULIDs, the shim6 protocol does not require the ULID to be reachable. ULID Reachability is a useful optimization for starting the communication, but if the communication commenced with unreachable ULIDs, and you could find the locators associated with the ULID, then you could use the same socket API, and it could work. One possible approach is to use the ULID as a lookup key to find a set of locators. One approach here is to use the approach of C-ULAs as the prefix for such unreachable ULIDs with HBA/CGA for the interface ID field. The lookup could be handled by the DNS with an ID RR type. The shim6 protocol would need to identify an Unreachable ID as the initual ULID and perform ULID lookup and context state setup before sending initial packet. This concept could be extended from individual host addresses to network prefixes.
For Traffic Engineering the DNS RR type could return SRV records for communicating relative preferences between locators. However for sitewide settings this might be undertaken via a DHCPv6 option. This application is limited because the peer would only change locators on failure rather than on some site-defined trigger. This could be undertaken by routers performing locator rewriting with payload extension headers to convey the intermediary rewriting to the end hosts.
With respect to the potential use of IPv4, it was noted that while IPv4 locators may be feasible, this does not extend to IPv4 as ULIDs. ULIDs are still IPv6 addresses because we need CGA/HBA properties. This does not solve the IPv4 case cause we don't have NAT traversal. In the proxy case, this is not such an issue because the proxy could be the NAT device itself What combinations are interesting? The rewriting one is the most complex one, is this interesting?
Questions / Comments:
It was noted that locators could include V4 addresses as well as V6 addresses
It was asked why do we need this for control messages? For REAP this additional information would be useful, and also in the case of ingress filtering, you may need this in the first packet.
If there is rewriting by routers then the source address need not be considered any more. It's the destination addresses that require authentication in this form of the shim6 model.
Proxy Shim6 - Marcelo Bagnulo
[presentation]
The intended outcome of this work is teasier deployment of shim6 by allowing shim6 to offload the shim6 protocol work to specialized mid-ware, enabling nodes with access to shim6 without host-based stack surgery, address portability and site-level management enforcement for site-based traffic engineering management.
Questions / Comments:
If you trigger the context establishment right after get the DNS responds, aren't you losing time here? How long would context establishment take in this case? This context establishment could be done in parallel with the copnventional use of the initial ULID as the locator.
Once you offload this to a box in the middle you've extended the fate sharing domain. Can you back up this middleware ("proxy shim6")? The good news is that context can be recovered in shim6. The problem is when you have a packet with ULID and no locator mapping.
The adopted goal of address portability support explicitly drives you into CMULAs, DNS ALGs, ULID RR, firewall components, CGAs and not HBAs. If you don't want address portability then this is avoidable
If the hosts knew to ask for ULIDs then why would you need the DNSALGs (i.e. make DNSSEC work) The synthesis DNS responses are an issue here. It is more robust if you don't need avoid this.
Simplifying Proxy Shim6 - Christian Vogt
[presentation]
This is positioned as a potential optimisation of the proxy shim6 concept, specifically looking at the issue of egress router selection and attemting to obviate the need to special routing and tunnels within the end site, and avoiding the use of crypto addresses in hosts.
Special intrasite routing has the advantage that little synchronization is needed between proxies Drawbaks include administrative complexity, limited traffic engineering, router renumbering for locator changes, new addresses in site due to fixed ULID prefix. Would be good if we could avoid having ulids with a specific prefix to trigger renumbering.
Using the proxy shim6 in the border routers, different mechanisms for sync, but synch is needed Complication #2: lack of support of stateless autconf, keys must be shared between the proxies, if the host want to use this for a different use, then we need ring signatures. It would be easier if other address autoconf could be used.
Validation using a mapping interface as a means of avoiding crypto addresses. Both ends need to do the validation, for hosts is bad, because this is needed for very host pair commiunication. If you do it per prefix, then it scales much better. There may be different trust models with the different prefix or address mapping.
Questions / Comments:
It was noted that this approach is only needed for legacy v6, this is not needed for shim6 capable hosts. If there is a mixed scenario, then you may need to tell the host the different configurations. What needs more discussion is what the primary goal here: provider independence or legacy host support? Depending what you pick, you end us with different solutions.
It is useful to think of this in a layering fashion. If you use C-ULA in the site and a GPRS interface, and could present to the peer the C-ULA and the GPRS address, it is not infeasiuble to provide this flexibility.
Path Selection - Olivier Bonaventure & Luigi Iannone
[presentation]
The host don't usually has the vision of the cost of the different paths, the ISP does. We need to understand which are the goals for the different TE configurations, using the Schiller clasification. Provide a service that has more information than the hosts and provides a service to the hosts, providing locator selection. The host will send a list of host addresses available and the service will return the pairs that are best using certian criteria
Questions / Comments:
It was clarified that this service would be provided by the ISP and the ISP would need to understand the different connectivity that the host has. It was noted that if the connectivity options span multiple ISPs then the ISPs would need to coordinate.
The service was envisaged to operate as an anycast service, and was intended to offer the same answers across different instances of the service operated by different providers when provided with the same query.
Next Steps Work Items - Iljitsch van Beijnum
[presentation]
A discussion on what's missing from the base specification of Shim6 to consider what new work the WG should take on.
We are not yet finished with the work on the base protocol specification, and further work should wait until these documents had completed the publicaiton review process.
Potential areas for further study include ingress filtering, ICMP, tunnels, and source address routing as they relate to multi-addressed hosts. Also initial failures, mapping mechanisms, reachability detection, TE,proxy shim6 and the more general consideration of rewriting addresses in routers and NATs.
Questions / Comments:
It was noted that the aspect of operation of multi-addressed hosts and their interaction with the local routing environment was an intrinsic issue with IPv6 rather than SHIM6, and the 6MAN WG is studying this topic.
It was observed that IKE may not be that hard, because it already has NAT traversal, so that may work with 1:1 address translating NATs. This may require a broader level of consensus in the IETF to handle referrals appropriately.
Further work may ential exploration of Proxy shim6 with DNS based validations, since it may be an easier to explore.
It was also proposed that the WG could merge the different proxy shim6 proposals.