[Search] [txt|pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02                                                      
IPv6 Operations                                                J. Massar
Internet-Draft                                             Unfix / SixXS
Expires: December 27, 2004                                 June 28, 2004


                      AYIYA: Anything In Anything
                      draft-massar-v6ops-ayiya-01

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   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 will expire on December 27, 2004.

Copyright Notice

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

Abstract

   This document defines a tunneling protocol that can be encapsulated
   in any other protocol. This protocol uses authentication tokens,
   allowing multiple identities to exist on the same endpoint and thus
   also to created tunnels from/to the same NAT and also making it
   possible to automatically change the endpoint of the tunnel. This
   protocol is intended as an alternative to the proto-41 protocol in
   use for tunneling IPv6 over IPv4 packets over the Internet but can
   also be applied in multihoming solutions. Due to the authentication
   this protocol is especially useful for dynamic non-24/7 endnodes
   which are located behind NATs and want to use a IPv6 Tunnel Broker,
   for instance. The protocol can carry any payload and thus is not
   limited to only IPv6 over IPv4 but can also be used for IPv4 over
   IPv6 and many other combinations of protocols.



Massar                 Expires December 27, 2004                [Page 1]


Internet-Draft        AYIYA: Anything In Anything              June 2004


Table of Contents

   1.  Requirements notation  . . . . . . . . . . . . . . . . . . . .  3
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  AYIYA Packet Format  . . . . . . . . . . . . . . . . . . . . .  4
     3.1   Identity Length (IDLen)  . . . . . . . . . . . . . . . . .  5
     3.2   Identity Type (IDType) . . . . . . . . . . . . . . . . . .  5
     3.3   Signature Length (SigLen)  . . . . . . . . . . . . . . . .  5
     3.4   Hashing Method (HshMeth) . . . . . . . . . . . . . . . . .  6
     3.5   Authentication Method (AutMeth)  . . . . . . . . . . . . .  6
     3.6   Operation Code (OpCode)  . . . . . . . . . . . . . . . . .  7
     3.7   Next Header  . . . . . . . . . . . . . . . . . . . . . . .  7
     3.8   Epoch Time . . . . . . . . . . . . . . . . . . . . . . . .  7
   4.  AYIYA Heartbeat  . . . . . . . . . . . . . . . . . . . . . . .  9
   5.  Signing the packet . . . . . . . . . . . . . . . . . . . . . .  9
     5.1   Hashing the packet . . . . . . . . . . . . . . . . . . . . 10
     5.2   Signing with a Shared Secret . . . . . . . . . . . . . . . 10
     5.3   Signing with a Public/Private Key  . . . . . . . . . . . . 10
   6.  Identity information in DNS  . . . . . . . . . . . . . . . . . 11
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   9.  Scenarios  . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     9.1   Using AYIYA for IPv6 Tunnel Brokers  . . . . . . . . . . . 13
     9.2   Tunneling to multiple endhosts behind a NAT  . . . . . . . 14
     9.3   Multihoming using AYIYA  . . . . . . . . . . . . . . . . . 15
     9.4   Mobility using AYIYA . . . . . . . . . . . . . . . . . . . 18
   10.   IANA Considerations  . . . . . . . . . . . . . . . . . . . . 18
   11.   References . . . . . . . . . . . . . . . . . . . . . . . . . 18
       Author's Address . . . . . . . . . . . . . . . . . . . . . . . 20
       Intellectual Property and Copyright Statements . . . . . . . . 21





















Massar                 Expires December 27, 2004                [Page 2]


Internet-Draft        AYIYA: Anything In Anything              June 2004


1.  Requirements notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

2.  Introduction

   Many users are currently located behind NATs which prohibit the usage
   of proto-41 IPv6 in IPv4 tunnels [RFC3056] unless they manually
   reconfigure their NAT setup which in some cases is impossible as the
   NAT cannot be configured to forward proto-41 ([RFC1933]) to a
   specific host. There might also be cases when multiple endpoints are
   behind the same NAT, when multiple NATs are used or when the user has
   no control at all over the NAT setup. This is an undesired situation
   as it limits the deployment of IPv6 [RFC3513], which was meant to
   solve the problem of the disturbance in end to end communications
   caused by NATs, which where created because of limited address space
   in the first place.

   This problem can be solved easily by tunneling the IPv6 packets over
   either UDP [RFC0768], TCP [RFC0793] or even SCTP [RFC2960]. Taking
   into consideration that multiple separate endpoints could be behind
   the same NAT and/or that the public endpoint can change on the fly,
   there is also a need to identify the endpoint that certain packets
   are coming from and endpoints need to be able to change e.g. source
   addresses of the transporting protocol on the fly while still being
   identifiable as the same endpoint. The protocol described in this
   document is independent of the transport and payload's protocol. An
   examples could be IPv6-in-UDP-in-IPv4, which is a typical setup that
   can be used by IPv6 Tunnel Brokers [RFC3053].

   This document does not describe how to determine the identity,
   signature type or the inner and outer protocols. These should be
   negotiated manually or automatically by e.g. using TSP or a relevant
   protocol which is capable of describing the configuration parameters
   of AYIYA tunnels. Seperate documents for the configuration protocols
   supporting AYIYA should include the details on how this is done.

   Additionally this document describes how AYIYA could be used in both
   a multihoming and in a mobility scenario.










Massar                 Expires December 27, 2004                [Page 3]


Internet-Draft        AYIYA: Anything In Anything              June 2004


3.  AYIYA Packet Format

   The AYIYA protocol is put inside the data part of either UDP
   [RFC0768], TCP [RFC0793] or SCTP [RFC2960] which are the currently
   defined transport protocols, future transport protocols could also be
   used. The transport protocol can be run over both IPv4 or IPv6 or any
   other future protocol. Schematically, this will look like the
   following diagram.

   +--------+                    +----------+
   | Sender | <--- Internet ---> | Receiver |
   +--------+                    +----------+

   A complete on the wire packet will have the following format.

   +-------------------------------+
   |       Delivery Header         |
   |        IPv4/IPv6/...          |
   +-------------------------------+
   |       Transport Header        |
   |        TCP/UDP/SCTP/...       |
   +-------------------------------+
   |          AYIYA Header         |
   +-------------------------------+
   |        Payload packet         |
   +-------------------------------+

   The AYIYA protocol has a header with the following format.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | IDLen | IDType| SigLen|HshMeth|AutMeth| OpCode|  Next Header  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Epoch Time                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                                                               :
   :                            Identity                           :
   :                                                               :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                                                               :
   :                            Signature                          :
   :                                                               :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   All fields are in network byte order (Big Endian). The base AYIYA
   header without an identity or signature is 8 bytes.




Massar                 Expires December 27, 2004                [Page 4]


Internet-Draft        AYIYA: Anything In Anything              June 2004


3.1  Identity Length (IDLen)

   The IDLen (Identity Length) Field defines the length of the Identity
   Field in a power of 2 in octets.

   e.g. a Lenght of 4 is 2^4 = 16 bytes.

3.2  Identity Type (IDType)

   The Identity Type specifies what kind of Identity is included in the
   header. The Idenity field is used by the receiver to determine which
   sender sent the packet, this is done as there is an assumption that
   the source endpoint, the source IP address or the source port, may
   change arbitrarily which will be the case when the sender is behind a
   NAT, using DHCP, PPP or using IPv6 privacy extensions [RFC3041] and
   thus has a changing address. Even though the endpoint is suspectible
   to change, the Identity will remain the same unless negotiated
   otherwise. Currently defined Identity types are:

    - 0x0 None
    - 0x1 Integer
    - 0x2 ASCII string

   Types 0x3 till 0xf are reserved for future usage.

   The type of identity used by an AYIYA tunnel is negotiated either
   manually or automatically outside this protocol, these fields are
   included to allow verification of the type and also to allow multiple
   types to be used by one receiver at the same time. ASCII strings are
   NULL padded when they do not fill the complete identity field. The
   types are multifunctional, e.g. type 0x01 could contain an IPv4
   address when the length of the identity is 0x2 or could contain an
   IPv6 address when the length is 0x4. A string could contain DNS
   names. The exact content of the Identity Field is defined by the
   users of this protocol and out of scope of this document.

   If the Identity Type is None, the Identity Field is absent from the
   packet. The Signature Field, if present, will then directly follow
   the Epoch Time Field. In case the Signature Field is not present the
   payload will directly follow the Epoch Time field. The Identity
   Length Field must be 0 in this case.

3.3  Signature Length (SigLen)

   The SigLen describes the length of the hash and is specified in
   octets divided by four. e.g. a SigLen of 3 means the signature is 12
   bytes long, a SigLen of 15 means that the Signature is 60 bytes long.
   The protocol thus allows for a maximum signature of 480 bits.



Massar                 Expires December 27, 2004                [Page 5]


Internet-Draft        AYIYA: Anything In Anything              June 2004


3.4  Hashing Method (HshMeth)

   The HshMeth (Hashing Method) bits describe the type of the Hashing
   Method used to create the signature of the packet. By hashing the
   complete packet we can verify that the packet did not change during
   transit between sender and receiver. Currently defined Hashing
   Methods are: - 0x0 No hash - 0x1 MD5  [RFC1321] - 0x2 SHA1 [RFC3174]
   As there are known collisions for MD5 it is advised to use SHA1 as a
   default Hashing Method. Hashing Methods 0x3 to 0xf are reserved for
   future usage.

   When the Hashing Method is 0x0, AuthMeth and SigLen MUST also be set
   to 0 and the packet doesn't include a Signature, the payload, defined
   by the Next Header, then directly follows the Identity field, which
   may also be absent depending on it's type.

3.5  Authentication Method (AutMeth)

   AuthMeth (Authentication Method) describes the type of the
   Authentication Method. By authenticating the packet we can verify
   that the sender really originated from the sender, of course assuming
   that the Authentication Method has not been compromised. The AYIYA
   protocol doesn't have any options for encryption. Encryption can be
   done in the payload. The currently defined Authentication Methods
   are:

    - 0x0 No authentication
    - 0x1 Hash using a Shared Secret
    - 0x2 Hash using a public/private key method

   Authentication Methods 0x3 to 0xf are reserved for future usage.

   In the case where an implementation does not support or expect the
   received Identity or Signature Type (e.g. because it was configured
   for a different type) it MUST silently discard the packet. The user
   may be notified of this event.















Massar                 Expires December 27, 2004                [Page 6]


Internet-Draft        AYIYA: Anything In Anything              June 2004


3.6  Operation Code (OpCode)

   The Operation Code can request special operation on the packet.
   Currently

    - 0x0 No Operation / Heartbeat
    - 0x1 Forward
    - 0x2 Echo Request
    - 0x3 Echo Request and Forward
    - 0x4 Echo Response

   The No Operation OpCode allows the packet to be used for updating the
   latest received time, see the next section for the rationale why this
   packet is also dubbed a Heartbeat Packet. The Forward OpCode
   specifies that this is a normal packet which is to be forwarded. The
   Echo Request OpCode requests that the payload is echoed back to the
   sender, the OpCode of the returned packet should then be set to Echo
   Response. The payload of the Echo Request packet MUST NOT be
   forwarded. When the OpCode is set to Echo Request and Forward then
   the packet must be echoed back to the sender and also forwarded as a
   normal packet. This allows the Heartbeat functionality, as discussed
   in the next chapter, to be integrated into the normal packet stream.
   It can also be used to ensure that a packet is delivered to the other
   end of the tunnel. Values 0x3 till 0xf are reserved for future
   extensions.

3.7  Next Header

   The Next Header, like in IPv6, contains the protocol value of the
   payload following the AYIYA Packet Header. There is no length field
   as that can be deduced from the protocol that is carrying this
   packet.

3.8  Epoch Time

   Epoch Time is the time in seconds since "00:00:00 1970-01-01 UTC".
   Both the sender and the receiver are advised to be synchronized using
   NTP [RFC2030] to make sure that their clocks clocks do not differ too
   much even after travelling the intermediate networks between the
   sender and the receiver. The number of seconds since the above date
   are stored in a 32 bit unsigned integer in network byte order.

   The Epoch Time is included to be able to guard against replay
   attacks. See the Security Considerations section for more details.







Massar                 Expires December 27, 2004                [Page 7]


Internet-Draft        AYIYA: Anything In Anything              June 2004


   The Epoch Time will loop in 2038 when the 32 bit unsigned integer
   reaches it's maximum value. This will cause that the difference
   between the two times is larger than the advised timeout time even
   though the difference is not that big. To avoid a service
   interruption, because the time in the packet is not inside the limits
   of the clock shift time, every implementation MUST handle times in
   the range (0-timeout)..0 specially and compensate the loop, e.g. by
   shifting away from the looptime. Typical C code which handles the
   verification of the epochtime is included as an example:

   // epochtime = epochtime as received in the packet
   // Don't forget to convert the byteorder using ntohl()
   bool ayiya_checktime(time_t epochtime)
   {
      // Number of seconds we allow the clock to be off
      #define CLOCK_OFF 120
      int i;

      // Get the current time
      time_t curr_time = time(NULL);

      // Is one of the times in the loop range?
      if ( (curr_time  >= -CLOCK_OFF) ||
           (epochtime >= -CLOCK_OFF))
      {
         // Shift the times out of the loop range
         i = (curr_time + (CLOCK_OFF*2)) -
             (epochtime + (CLOCK_OFF*2));
      }
      else i = curr_time - epochtime;

      // The clock may be faster, thus flip the sign
      if (i < 0) i = -i;

      // Compare the clock offset
      if (i > CLOCK_OFF)
      {
         // Time is off, silently drop the packet
         return false;
      }

      // Time is in the allowed range
      return true;
   }

   Theory for the above: for simplicity let's assume the loop is around
   10000. Sender sends an epochtime of 9990, but the receiver's time is
   at 10 already, thus we apply the shift and the times become: (9990 +



Massar                 Expires December 27, 2004                [Page 8]


Internet-Draft        AYIYA: Anything In Anything              June 2004


   240)%10000 = 230 and (10 + 240)%10000 = 250 the difference !(250 -
   230) is 20, which is in the allowed clock_off range. If we didn't
   apply this compensation the difference would have been !(10 - 9990) =
   9980 seconds which would mean the packet would have been dropped even
   though the packets time is valid.

4.  AYIYA Heartbeat

   As the receiver will disable the tunnel after it has not received a
   packet from the sender after a configured time the sender should send
   packets to the other side of the tunnel with the Next Header field
   set to 59 (No Next Header) but the payload may contain data which is
   private to the implementation. The implementation could include a
   sequence number in the payload like is common with ICMP echo
   [RFC2463] packets. The receiver will reply on reception of this
   packet returning the exact payload the sender transmitted allowing
   the sender to compare the information and deduce latency information
   and other statistical information from it using the implementation
   specific data contained in the payload. This packet allows the sender
   to test the tunnel's functionality. If the signature is not correct,
   either because of the wrong shared secret, wrong hash, wrong identity
   or connectivity problems, the sender will not get a reply and could
   notify the user of this situation.

   Senders should send these packets once per 60 seconds as the receiver
   is usually configured to disable the tunnel after it has received no
   packets for a timeout time of 120 seconds. An implementation could
   choose to not send the heartbeat packet when it has already sent a
   packet in the last 60 seconds thus avoiding a small overhead in
   transmission and processing of these extra heartbeat packets.
   Receivers MUST handle every correctly verified packet as the last
   received one.

   A side effect of this Heartbeat Packet is that a NAT will update it's
   mappings and keep the same source/destination ports in cases where
   AYIYA is encapsulated inside UDP, for instance.

   An implementation could choose to not send any heartbeat packets, but
   this will cause the connecitivity, provided by the tunnel, to be
   interrupted until the sender sends a packt again.

5.  Signing the packet

   When there is no Hashing there neither is no signing of the packet
   and the header won't include a Signature.

   If a received packet contains flags that the packet contains a hash
   or that the packet contains an authentication then the receiver must



Massar                 Expires December 27, 2004                [Page 9]


Internet-Draft        AYIYA: Anything In Anything              June 2004


   verifiy that the signature provided is correct by following the same
   procedure as taken by the sender and comparing the results of the
   signatures. When the signatures match the packet can be processed
   further. When the signatures do not match the receiver MUST silently
   ignore the packet and may notify the user.

5.1  Hashing the packet

   When there is no Authentication we create the signature of the packet
   by initializing the signature of the packet to NULL. The rest of the
   fields and the payload should also be initialized as to be sent over
   the wire. The signature is then made over the complete packet using
   the Hashing Method defined by the type. Thus over the AYIYA header
   and the payload.

   This method allows verification that the packet has not been
   incidentally mangled along it's route to the receiver. It does not
   provide any security or authenticity that the packet has been
   forcefully mangled.

5.2  Signing with a Shared Secret

   To create the signature of the packet, the Signature Field MUST be
   set to the signature of the shared secret, this signature is made
   using the same hashing method as the one specified in the Signature
   Type Field. The signature is then made over the complete packet, thus
   the AYIYA header and the payload. By hashing the shared secret we
   allow shared secrets of arbitrary lengths to be used. Which shared
   secret is used is out of scope of this document and this should be
   described by manual or automatic configuration documents which should
   describe the definition of the shared secret.

   The result is stored in the Signature field, which contains the
   signature of the shared secret while hashing.

   Implementations could precache the hashed shared secret and would
   thus not require the knowlegde of the real shared secret.

   This method thus allows verification that the packet has not been
   modified along it's path from sender to receiver and also allows
   verification that the sender or receiver, who should be the only
   parties knowning the shared secrets, where the originators of this
   packet. This withouth sending the shared secret over the network.

5.3  Signing with a Public/Private Key

   The Signature Field of the header is initialized to NULL. The rest of
   the fields and the payload should also be initialized as to be sent



Massar                 Expires December 27, 2004               [Page 10]


Internet-Draft        AYIYA: Anything In Anything              June 2004


   over the wire. A hash defined by the HshMeth Field is then calculated
   over the complete packet. After that the Public / Private Key
   signature is calculated, the result of which is stored in the
   Signature Field.

6.  Identity information in DNS

   Some of the Identity Types could represent an IPv4 or IPv6 address or
   a hostname. Using normal (reverse) DNS lookup procedures the
   additional properties relating to these identities can then also be
   found out using DNS. These properties could be altnerate endpoint
   addresses, pointers to home agents or public keys. This can be used
   for the multihoming and mobility scenarios to bootstrap the initial
   connection. When a receiver receives the first packet from a, upto
   then unknown identity, it could lookup the identities additional
   properties like it's public key to be able to authenticate the
   received packet.

7.  Acknowledgements

   The protocol presented has formed during the existence of SixXS
   [SIXXS] to allow the users of the various Tunnel Servers provisioned
   by SixXS to have a dynamic non-static IPv4 endpoint which could even
   be located behind a NAT. This protocol is the natural successor of
   the combination of the proto-41 tunneling protocol and the SixXS
   Heartbeat protocol.

   Thanks to Christian Strauf, Brian Carpenter and Pim van Pelt for
   valuable comments which improved this document and therefore the
   protocol a lot.

8.  Security Considerations

   The shared secret used MUST never be made publicly available to 3rd
   parties otherwise that 3rd party could sign a packet and
   automatically reconfigure the tunnel endpoint. This would enable a
   3rd party to send traffic in both directions and thus posing as the
   actual user.

   The inclusion of the Epoch Time along with the verification on the
   receiver side should guard against replay attacks. The receiver MUST
   ensure that the time difference between local clock and the epochtime
   never differ for more than 60 seconds. This allows for a tolerance of
   latency and time-shifts.

   Note that the Epoch Time doesn't guard against resending of the same
   packet. A solution could be to add a sequence number in the AYIYA
   protocol but that would overcomplicate the receivers as they would



Massar                 Expires December 27, 2004               [Page 11]


Internet-Draft        AYIYA: Anything In Anything              June 2004


   need to keep state and even re-order packets, which is something that
   is not wanted with a protocol that is built to allow packets to drop.
   Upper layer protocols should have protection mechanisms against this.
   e.g. TCP has it's own sequence numbering.

   Any packet that is not well formed or contains a invalid signature
   MUST be silently dropped, appropriate logging may be done of these
   issues but in that case a rate limit MUST be applied to not clutter
   the logs with these messages. Invalid signatures MUST be handled as
   possibly being spoofed, thus no packet MUST be sent back as these
   packets would then go to the spoofed source address.

   As a side effect of this protocol, when a sender can not or does not
   send a packet in time, the tunnel is detected as defunct and the
   receiver will dispose of it. This could be the case when the sender's
   connectivity is interrupted. Disposition of the tunnel will also make
   sure that no packets will be forwarded over the tunnel to an endpoint
   which might not be expecting this kind of traffic as it is not the
   host that heartbeated the last time. This situation could arise for
   instance when DHCP changes the endpoint address or a host which dials
   into a PPP pool disconnects, after which the next dialin, by another
   host receives the former hosts endpoint address.

   This document specifies a tunneling protocol which can circumvent
   administrative policies implied by a firewall. This firewall can
   prohibit the communication between sender and reciever. If such a
   policy is in place, then that is an administrative policy which
   should not be tried to be circumvented. Using tunneling in general
   opens up a new hole into a network which might be used for gaining
   access into that network.

   When and one or both of the outer addresses is a [RFC3041] address,
   any process that receives the AYIYA packets can still make the
   relation to that single host as the Identity in the AYIYA packet
   doesn't change. The limited privacy effect of RFC3041 is thus removed
   in this case.

9.  Scenarios

   As AYIYA is a generic tunneling protocol it can be used in many
   different scenario's amongst which the scenarios described in this
   section.

   Note that TEST-NET [RFC3300] addresses used in the scenarios could
   never reach a Tunnel Server over the public Internet due to filtering
   of these documentation prefixes.





Massar                 Expires December 27, 2004               [Page 12]


Internet-Draft        AYIYA: Anything In Anything              June 2004


9.1  Using AYIYA for IPv6 Tunnel Brokers

   The main scenario where AYIYA is intended to be used is for solving
   the problem where a IPv4 host is behind a NAT and wants to tunnel to
   a Tunnel Server [RFC3056]. As many NAT's don't support forwarding
   protocol 41 or require manual configuration of the NAT, using AYIYA
   and encapsulating the AYIYA packet including the payload inside IPv4
   UPD is a good solution. The AYIYA packet includes an identity, thus
   the endpoint address of the client does not need to be known and the
   tunnel can be brought and kept up up at wish by the user when it's
   client notifies the Tunnel Server of it's existence by sending AYIYA
   packets.

   This type of tunnel will generally use a Identity Type of 0x3, the
   Identity Field will contain the IPv6 address of the endpoint of the
   tunnel from the direction where the packet is coming from, the
   Signature Type will be 0x2 (SHA-1).

     192.0.2.2               192.0.2.1
   2001:db8::2/64          2001:db8::1/64
   +----------+             +--------+
   |  Tunnel  |<----------->| Tunnel |
   |  Client  |             | Server |
   +----------+             +--------+

   The packet send over the wire will have the following format:

   +---------+
   |  IPv4   |
   +---------+
   |   UDP   |
   +---------+
   |  AYIYA  |
   +---------+
   |  IPv6   |
   +---------+
   | Payload |
   +---------+

   This setup causes a per-packet overhead of: 20 (IPv4) + 8 (UDP) +
   8+16+20 (AYIYA+Identity+Signature) = 72 bytes. This allows
   encapsulation of packets of 1428 bytes over Ethernet, which has a MTU
   of 1500 bytes. As the minimum MTU of IPv6 packets is 1280 bytes, any
   medium with at least an MTU of (1280 + 72 =) 1352 bytes can be used
   for AYIYA without having to fragment the packets.






Massar                 Expires December 27, 2004               [Page 13]


Internet-Draft        AYIYA: Anything In Anything              June 2004


9.2  Tunneling to multiple endhosts behind a NAT

   This scenario demonstrates a typical situation where this protocol
   will mainly be used: tunneling to multiple endhosts behind a NAT. In
   this scenario the Tunnel Server acts as a receiver in server mode
   which does not initiate any tunneling as it does not know the source
   endpoint of the clients, which might change at arbitrary timepoints.
   In this scenario the server is assumed to have a static endpoint. The
   server does not send heartbeats to check connectivity, it is up to
   the client to send the heartbeats at the agreed regular intervals
   making sure the server does not dispose of the tunnel. This setup
   allows both clients behind the NAT to change their private IPv4
   addresses and also allows the NAT to change its public IPv4 or source
   port numbers. The server will notice the changes of source IP or port
   numbers and can reconfigure its tunnel to send to the specific
   host:port combination for which a mapping will exist at the NAT and
   the packet can go through the NAT.

     10.0.0.0/8     NAT    192.0.2.0/24
                     |
   +----------+  (1) | (2)  +--------+
   | Client A |------|------|        |
   +----------+      |      | Tunnel |
   +----------+      |      | Server |
   | Client B |------|------|        |
   +----------+  (3) | (4)  +--------+
                     |


   (1) = src = 10.10.0.1:1234, dst = 192.0.2.42:3740
   (2) = src = 192.0.2.5:4321, dst = 192.0.2.42:3740
   (3) = src = 10.10.9.2:7890, dst = 192.0.2.42:3740
   (4) = src = 192.0.2.5:5678, dst = 192.0.2.42:3740

   AYIYA is capable of crossing any NAT. As an AYIYA Server uses the
   AYIYA port as the source port and the address that received the
   initial AYIYA packet from the client as a source address, Restricted
   Cone NATs, Port-Restricted Cone NATs and Symmetric NATs can be
   traversed. If the mapping would change the next packet coming from
   the client would update the host:port mapping on the Tunnel Server.

   The four main types of NAT's are described in the Teredo document.









Massar                 Expires December 27, 2004               [Page 14]


Internet-Draft        AYIYA: Anything In Anything              June 2004


   This scenario would typically encapsulate AYIYA and the payload
   inside IPv4 and UDP. Schematically this would look like:

   +---------+
   |  IPv4   |
   +---------+
   |   UDP   |
   +---------+
   |  AYIYA  |
   +---------+
   | Payload |
   +---------+


9.3  Multihoming using AYIYA

   AYIYA can also be used as a tunneling protocol for solving
   multihoming problems. For instance the following packet could be
   crafted which encapsulates IPv6 inside IPv6. The encapsulated packet
   could contain a source/destination address which could be described
   as the identifiers of this multihoming protocol. The outer IPv6
   addresses are the locators.





























Massar                 Expires December 27, 2004               [Page 15]


Internet-Draft        AYIYA: Anything In Anything              June 2004


   A typical Multihoming scenario. Site A is connected to the Internet
   using two independent upstream providers (Provider 1 and Provider 2).
   Every host inside Site A has two addresses, one from Provider 1
   (2001:db8:1000::/48) and one from Provider 2 (2001:db8:2000::/48).
   Both upstream providers correctly filter egress traffic making sure
   that only source addresses assigned to Site A from their own address
   space is sent to the Internet, thus protecting against spoofing. The
   SiteRouters must thus make sure that only the correctly sourced
   packets are sent outward. Either the Host or the SiteRouters could
   support AYIYA, in the first case the SiteRouters MUST never do any
   additional AYIYA tunneling, this can be accomplished easily by
   checking that the IPv6 Next Header or IPv4 Protocol field doesn't
   contain the value mentioning that the next header is an AYIYA header.
   If this value is not set to be an AYIYA header, the SiteRouters MAY
   initiate AYIYA traffic to the remote host or site using their Site
   Identifiers. This allows host-host, host-site and also site-site
   multihoming.

   +---------------------------------------+
   |            +------------+      Site A |
   |            |   Host A   |             |
   |            +------------+             |
   |              |         |              |
   |              |         |              |
   | +--------------+     +--------------+ |
   | | SiteRouter 1 |     | SiteRouter 2 | |
   | +--------------+     +--------------+ |
   |        |                    |         |
   +--------|--------------------|---------+
            |                    |
     +--------------+     +--------------+
     |  Provider 1  |     |  Provider 2  |
     +--------------+     +--------------+
            |                    |
            |                    |
     +------------------------------------+
     |           The Internet             |
     +------------------------------------+
                      |
               +------------+
               |   Host B   |
               +------------+

   The hosts communicating with each other using this setup would need
   to agree on which identities, hashing, authentication methods and
   shared secrets or private/public keys they use. This is out of scope
   for this document.




Massar                 Expires December 27, 2004               [Page 16]


Internet-Draft        AYIYA: Anything In Anything              June 2004


   The following figure depicts an example IPv6 TCP packet which is
   encapsulated using AYIYA inside IPv4 or IPv6 which demonstrates its
   protocol independency. The Next Header field of the outer IPv6 packet
   directly contains a IPv6 Next Header value of IANA:TBD. The Next
   Header field of the AYIYA Header contains the value of 41 (IPv6). The
   locators used are IPv4 or IPv6 addresses, while the identifiers and
   the actual protocol addresses that are being multihomed are IPv6.
   This scenario could allow a host to decide to start communicating
   with another host over IPv4 when an IPv6 route is not available or
   doesn't have the required properties, based on latency for instance.

   +---------+
   |IPv4/IPv6|
   +---------+
   |  AYIYA  |
   +---------+
   |  IPv6   |
   +---------+
   |   TCP   |
   +---------+
   | Payload |
   +---------+

   If the locator of a host changes, that host can directly send a
   heartbeat packet to the other host notifying that host of the change.
   The receiving host recognises the new locator as a valid source as
   the signature can be verified and sets it's outgoing packets to use
   this new endpoint. As the identifiers are encapsulated, existing
   connections or communications won't notice this change.






















Massar                 Expires December 27, 2004               [Page 17]


Internet-Draft        AYIYA: Anything In Anything              June 2004


9.4  Mobility using AYIYA

   AYIYA could be used in a mobility situation for tunneling it's Home
   Address back to the Home Agent, thus acting as a normal tunnel
   situation and for the Remote Host it seems the communication is
   happening directly. In this case the remote host doesn't need to
   support AYIYA. When the Remote Host does support AYIYA, it could also
   directly setup a tunnel with the mobile host, circumventing that
   traffic is sent over the Home Agent. The Remote Host can determine if
   a host supports AYIYA by looking up properties in DNS and use a
   Public/Private Key algorithm to authenticate the packets without
   prior information, e.g. the keys, needing to be available. The
   following diagram illustrates this.

   +-------------+           +------------+
   | Mobile Host |<--AYIYA-->| Home Agent |
   +-------------+           +------------+
          ^                         ^
          |                         |
        AYIYA                   IPv4/IPv6
          |                         |
          v                         v
   +-------------+           +-------------+
   | Remote Host |           | Remote Host |
   |   + AYIYA   |           |             |
   +-------------+           +-------------+

   The exact mechanism for determining the public/private key and the
   identities used are out of scope for this document.

10.  IANA Considerations

   IANA will need to allocate a protocol number value for "AYIYA"
   allowing AYIYA packets to be directly encapsulated inside IPv4, IPv6
   or possibly any other future protocols.

   IANA will need to allocate a port number in the case where AYIYA is
   used over UDP [RFC0768], TCP [RFC0793] or SCTP [RFC2960] or any other
   protocol supporting port numbers. A port number request has been made
   through normal port allocation procedures requesting a system port.

11  References

   [RFC0768]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,
              August 1980.

   [RFC0793]  Postel, J., "Transmission Control Protocol", STD 7, RFC
              793, September 1981.



Massar                 Expires December 27, 2004               [Page 18]


Internet-Draft        AYIYA: Anything In Anything              June 2004


   [RFC1321]  Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
              April 1992.

   [RFC1933]  Gilligan, R. and E. Nordmark, "Transition Mechanisms for
              IPv6 Hosts and Routers", RFC 1933, April 1996.

   [RFC2030]  Mills, D., "Simple Network Time Protocol (SNTP) Version 4
              for IPv4, IPv6 and OSI", RFC 2030, October 1996.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2463]  Conta, A. and S. Deering, "Internet Control Message
              Protocol (ICMPv6) for the Internet Protocol Version 6
              (IPv6) Specification", RFC 2463, December 1998.

   [RFC2960]  Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
              Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M.,
              Zhang, L. and V. Paxson, "Stream Control Transmission
              Protocol", RFC 2960, October 2000.

   [RFC3041]  Narten, T. and R. Draves, "Privacy Extensions for
              Stateless Address Autoconfiguration in IPv6", RFC 3041,
              January 2001.

   [RFC3053]  Durand, A., Fasano, P., Guardini, I. and D. Lento, "IPv6
              Tunnel Broker", RFC 3053, January 2001.

   [RFC3056]  Carpenter, B. and K. Moore, "Connection of IPv6 Domains
              via IPv4 Clouds", RFC 3056, February 2001.

   [RFC3174]  Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1
              (SHA1)", RFC 3174, September 2001.

   [RFC3300]  Reynolds, J., Braden, R., Ginoza, S. and A. De La Cruz,
              "Internet Official Protocol Standards", RFC 3300, November
              2002.

   [RFC3513]  Hinden, R. and S. Deering, "Internet Protocol Version 6
              (IPv6) Addressing Architecture", RFC 3513, April 2003.

   [SIXXS]    Massar, J. and P. van Pelt, "SixXS - IPv6 Deployment &
              Tunnelbroker", <http://www.sixxs.net>.








Massar                 Expires December 27, 2004               [Page 19]


Internet-Draft        AYIYA: Anything In Anything              June 2004


Author's Address

   Jeroen Massar
   Unfix / SixXS
   Hofpoldersingel 45
   Gouda  2807 LW
   NL

   EMail: jeroen@unfix.org
   URI:   http://unfix.org/~jeroen/









































Massar                 Expires December 27, 2004               [Page 20]


Internet-Draft        AYIYA: Anything In Anything              June 2004


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property 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; neither does it represent that it
   has made any effort to identify any such rights. Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11. Copies of
   claims of rights made available for publication 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 implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard. Please address the information to the IETF Executive
   Director.


Full Copyright Statement

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

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assignees.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION



Massar                 Expires December 27, 2004               [Page 21]


Internet-Draft        AYIYA: Anything In Anything              June 2004


   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Acknowledgment

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











































Massar                 Expires December 27, 2004               [Page 22]