One document matched: draft-ietf-shim6-reach-detect-00.txt

INTERNET-DRAFT                                      Iljitsch van Beijnum
Jul 11, 2005

                        Shim6 Reachability Detection
                    draft-ietf-shim6-reach-detect-00.txt


   Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet Draft expires Jan 11, 2006.

   Copyright Notice

      Copyright (C) The Internet Society (2005).  All Rights Reserved.


Abstract

This draft discusses the issues of detecting failures in a currently
used address pair between two hosts and picking a new address pair to
be used when a failure occurs. The input for these processes are
ordered lists of local and remote addresses that are reasonably likely
to work. (I.e., not include addresses that are known to be unreachable
for local reasons.) These lists must be available at both ends of the
communication, although the ordering may differ. Building these address
lists from locally available information and synchronizing them with
the remote end are outside the scope of this document.

This text is for the most part based on discussions on the multi6 list,
several multi6 design team lists and the shim6 list, with notable
contributions from Erik Nordmark and Marcelo Bagnulo.


Van Beijnum             Expires January 11, 2006                [Page 1]

Internet-Draft        Shim6 Reachability Detection             July 2005


Suggestions and additions are more than welcome.

1 Introduction

The most widespread mechanisms to ensure reachability in current
protocols are:

- Acknowledgments. For instance, in TCP each segment received is
  acknowledged immediately or after a short delay. Lack of
  acknowledgments leads to retransmissions, and eventually, session
  timeouts.

- Keepalives. In routing protocols it's customary to send keepalives at
  periodic intervals and look for either responses to local keepalives
  or for keepalives generated by the other side. If no keepalives or
  responses were received for some time the other side is declared
  unreachable.

- Monitoring and probing. IPv6 Neighbor Unreachability Detection
  monitors the progress of higher layer protocols, and in the absence
  of progress, probes the other side (when on-link) or the next hop
  with a directed neighbor solicitation message. If there is no answer,
  the other side (on-link) or router is declared unreachable.

None of these mechanisms seems like a good candidate to adopt for
end-to-end reachability detection, either because they duplicate
existing mechanisms or introduce unnecessary overhead.

In addition, exploring the full set of communication options between
two hosts that both have two or more addresses is an expensive
operation as the number of combinations to be explored increases very
quickly with the number of addresses. For instance, with two addresses
on both sides, there are four possible address pairs. Since we can't
assume that reachability in one direction automatically means
reachability for the complement pair in the other direction, the total
number of two-way combinations is eight. (Combinations = nA * nB * 2.)
Although links almost always work in two directions, routing protocols
and filters only work in one direction so unidirectional reachability
can happen. Without additional mechanisms, the practice of ingress
filtering by ISPs makes unidirectional connectivity likely.

In order to reduce packet overhead, it makes sense to have different
on-the-wire protocols for confirming existing reachability and full
exploration of potential reachability.

2 Determining reachability for the current pair

In discussions two models came up for determining whether the current
address pair used in ongoing communication still works.


Van Beijnum             Expires January 11, 2006                [Page 2]

Internet-Draft        Shim6 Reachability Detection             July 2005


The first model resembles IPv6 neighbor unreachability detection (NUD).
The idea is that when transport protocols see forward progress, they
inform the shim layer (positive feedback) and the shim layer doesn't
take any action. However, in the absence of positive feedback and in
the presence of outgoing traffic, the shim layer generates packets that
probe reachability. When the correspondent receives a probe, it sends
back an acknowledgment so the shim layer at the originating host knows
the address pair is still functional. When there are no acknowledgments
for several probes, a full reachability exploration is executed.

The second model ensures that all communication is bidirectional. So
when communication isn't bidirectional, there must be a failure and
again, a full reachability exploration is executed. Although most
protocols generate traffic in both directions most of the time, there
are times when there is only legitimate traffic in one direction and
not the other. The shim layer monitors incoming and outgoing packets,
and when there are incoming packets but no regular outgoing data
packets, the shim generates keepalive packets. So when there is
outgoing traffic, there must be either regular incoming traffic, or
keepalives generated by the other side. If not, there is probably a
failure so the full reachability exploration procedure is executed.

There are several different tradeoffs between the two models:

- In the first model, the sending host detects the problem, in the
  second model, the receiving host detects the problem

- In the first model, a host can detect problems in either direction

- In the second model, a host can only detect problems in the receiving
  direction so it must depend on the correspondent to detect problems
  in the other direction

- The first model generates traffic in both directions, possibly
  competing with payload traffic in the high-volume direction

- The second model only generates traffic in the no-traffic direction,
  so there is never competition with payload traffic

- In absence of upper layer protocol feedback, the first model always
  sends periodic probes

- The second model doesn't require upper layer protocol feedback to
  suppress keepalives

There have been some discussions about positive versus negative
feedback. The first model doesn't have any use for negative feedback,
but needs positive feedback to reduce overhead. The second model has
little or no use for positive feedback, but may use negative feedback


Van Beijnum             Expires January 11, 2006                [Page 3]

Internet-Draft        Shim6 Reachability Detection             July 2005


to detect failures faster. However, using negative feedback from upper
layer protocols may prove challenging because upper layers can't be
trusted to provide the right quality or quantity feedback ("feedback
spamming").

3 Address pair exploration

In its essence, address pair exploration is very simple: just send
probes using every possible address pair, wait for something to come
back and possibly consider the round trip time.

In practice, doing a full address pair exploration is very undesirable
because of the large number of packets involved. This can be especially
harmful when a lot of hosts on a link start doing this for many of
their correspondents at the same time when there is a failure further
upstream.

At this time, we don't have a clear vision of what this protocol should
look like, except that it should be conservative in the number of
packets it transmits in average-case scenarios, and that it's vitally
important to reject very bad paths or address pairs.

Since the failures that have the largest potential to generate a lot of
local address pair exploration are the ones where a link that's used
for a lot of different sessions breaks, it makes sense to somehow
generalize results for one correspondent into optimizations in the
address exploration with another correspondent.

A promising way to avoid bad paths would be to send out a first probe,
wait for about a round trip for the old working path and then send
another probe, and after that do an exponential backoff. If either the
first or the second pair were reasonable choices, there is a workable
solution within several round trips.

4 Granularity

It has not been determined what the association/multiplexing
granularity of shim6 will be: host-to-host,
upper-layer-identity-to-upper-layer-identity (ULID) or session. By its
nature, the reachability detection works on address or locator pairs.
It would be highly inefficient if each session, or even each ULID pair,
would do its own address pair exploration. On the other hand, it would
also be undesirable force all sessions or ULID associations between
two hosts to use the same address pairs. This probably means that when
a failure is determined, all sessions or associations should act
accordingly, but when reachability is determined, each session or
association may react according to its own preferences.




Van Beijnum             Expires January 11, 2006                [Page 4]

Internet-Draft        Shim6 Reachability Detection             July 2005


5 NAT and firewall considerations

Since shim6 is chartered for IPv6 solutions only, and NAT compatibility
is not expected, and by most people, not desired in IPv6, there is no
requirement for this protocol to pass through Network Address
Translation devices. However, the protocol may be applicable outside
shim6, making NAT compatibility desirable.

It is absolutely essential that the shim6 negotiations and the
reachability detection packets are passed through filters or firewalls
wherever application packets are passed through. If the shim6
negotiation and reachability detection packets are filtered out, shim6
can't be used.

A more complex situation arises when the shim6 negotiation packets pass
through a firewall, but the reachability detection packets are blocked.
To avoid this complexity, it's highly desirable to make the shim6
negotiation and reachability detection part of the same protocol, so
either both are allowed through or both are blocked. However, the same
is true if this reachability detection mechanism is used in other
protocols. This makes it desirable to define the reachability detection
protocol such that it can be embedded in other protocols.

Since firewalls are in wide use, it's important to consider whether a
new protocol will be able to pass through most firewalls without
requiring changes to the filter configuration. On the other hand, it
may not be possible to come up with a protocol that would be allowed
through a large percentage of all firewalls without changes, so extra
effort in this area may produce limited results. Also, in the long run
firewall configuration will presumably be changed, so any compromises
would only have short term benefits but long term downsides.

6 Security considerations

To avoid exposing information (even if it's just the fact that an
address is reachable), hosts will probably want to limit themselves to
taking part in reachability detection with known correspondents. This
means that there must be identifying information and a nonce that is at
least hard to guess but easy to check in all reachability detection
packets.

4 Document and author information

This document expires January, 2006. The latest version will always be
available at http://www.muada.com/drafts/. Comments are welcome at: 

    Iljitsch van Beijnum

    Email: iljitsch@muada.com


Van Beijnum             Expires January 11, 2006                [Page 5]

Internet-Draft        Shim6 Reachability Detection             July 2005


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Van Beijnum             Expires January 11, 2006                [Page 6]