Subject: (ngtrans) draft-many-ngtrans-nd-dstm-00.txt comments ?

From: Philippe Bereski <[email-masked]>
Date: Wed, 14 Nov 2001 15:44:25 +0100

All,

Please find here attached the draft we plan to submit to the next IETF
meeting.
Thanks for all the comments you can made on it.

Abstract

   Today IPv6  nodes are generally  dual stacked.  With  its automatic
   configuration  of  tunnel  end   points,  [DSTM]  is  an  appealing
   transition mechanism, provided that an efficient dynamic allocation
   of IPv4 address process is  available.  The aim of this document is
   to  show  how  a  border  gateway  using  extensions  to  neighbour
   discovery [ND] can manage this allocation process.

Best regards,
Damien, Gilles, Philippe.

NGTRANS WG                                            Philippe Bereski
                                                      Gilles Diribarne
                                                         Damien Galand
                                                               Alcatel
Internet Draft
Title:draft-many-ngtrans-ND-DSTM-00.txt
Expires : April 2002                                     November 2001

       Dual Stack deployment using DSTM and neighbour discovery
		 <draft-many-ngtrans-nd-dstm-00.txt>

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.

Abstract

   Today IPv6  nodes are generally  dual stacked.  With  its automatic
   configuration  of  tunnel  end   points,  [DSTM]  is  an  appealing
   transition mechanism, provided that an efficient dynamic allocation
   of IPv4 address process is  available.  The aim of this document is
   to  show  how  a  border  gateway  using  extensions  to  neighbour
   discovery [ND] can manage this allocation process.

Index

      1. Introduction
      1.1 Scope of the document
      2. Using neighbour discovery for DSTM
      2.1 Communication initiated by a Dual Stack Host
      2.2 Communication initiated by a IPv4 only Host
      2.3 Tunneling of new ND messages
      3. Format of new ND messages
      3.1 RS for IPv4 address solicitation
      3.2 RA for IPv4 address allocation
      4. Security issues
      5. Conclusion
      6. References


1. Introduction

   Today  IPv6 nodes are  generally dual  stacked. With  its automatic
   configuration of  tunnel end points  (TEP), [DSTM] is  an appealing
   transition mechanism provided  that an efficient dynamic allocation
   of IPv4 address is available.  The  aim of this document is to show
   how a  border gateway using  extensions to neighbour  discovery can
   manage this allocation process.

   This document proposes 2 adaptations for ICMPv6 RA/RS messages.

   1.1 Scope of the document

   This document does not aim  at redefining DSTM itself. It only aims
   at  defining a  process  based  on ICMPv6  messages  to manage  the
   temporary allocation of IPv4 address to a dual stack host.

2. Using neighbour discovery for DSTM

   DSTM  defines that if  IPv4 routing  is not  supported in  the DSTM
   domain, IPv4 is tunnelled over  IPv6 from the Dual Stack Host (DSH)
   to  the TEP which  de-encapsulates and  then forwards  packets over
   IPv4 external  network.  A DSTM server is  responsible for managing
   the TEPs and maintaining a pool of IPv4 addresses.

   The TEP  is generally  the Y6/Y4 border  gateway, and  this gateway
   must  keep  track   of  the  association  of  the   IPv6  and  IPv4
   addresses. So, it  makes sense to consider that  the border gateway
   itself is the DSTM server. There is a need for a dialog between the
   Dual Stack  Node and  the border router  gateway, similarly  to the
   dialog  in the  neighbour  discovery process.  Handling  a pool  of
   addresses is a function that  is already accepted for mechanisms as
   NAT-PT.

   This section shows this  dialog when the communication is initiated
   by a Dual Stack Node or by a IPv4 only node.

   In the examples below, the following notation, borrowed from [DSTM]
   will be used:

     X    will designate  an IPv6 host with  a dual stack,  X6 will be
          the IPv6 address of this host and X4 the IPv4 address
     Y    will designate a DSTM border router at the boundary  between
          an IPv6 DSTM domain and an IPv4-only domain.
     Z    will designate an IPv4-only host and Z4 its address.
    ==>   means an IPv6 packet
    -->   means an IPv4 packet
    ++>   means a tunneled IPv4 packet  is  encapsulated  in  an  IPv6
          packet
    +=>   means  a  tunneled  IPv6  packet is  encapsulated in an IPv6
          packet
    ..>   means a DNS  query or   response. The  path  taken  by  this
          packet   does not matter in  the examples "a"  means the DNS
          name of a host

2.1 Communication initiated by a Dual Stack Node
        DNS
    X6       Y6/Y4      Z4
    |          |          |
    |. . . . . . . .>  Z  | - X6 asks the DNS for an AAAA for "Z"
    |<. . . . . . . error | - the DNS answers with an error
    |. . . . . . . .>  Z  | - X6 asks for the A RR for "Z"
    |<. . . . . . . . Z4  | - the answer is Z4
    |          |          | - The  application  sends  its  first  IPv4
    |          |          |   packet   which  arrives  to  the  Dynamic
    |          |          |   Tunneling Interface (DTI).
    |          |          | - X6 needs an IPv4 address (first use)
    |+=+=+=+=+>|          | - X6 queries the Y6/Y4 router server for an
    |          |          |   IPv4 address using RS request.
    |<+=+=+=+=+|          | - The  Y6/Y4  router  provides  a temporary
    |          |          |   IPv4 address  with a RA  answer to
    |          |          |   the6 node and cache the association.
    |    <=====|          | - The Y6/Y4 router sends dynamic  update to
    |          |          |   DNS with the temporary IPv4 address of X6
    |          |          |   for further IPv4 initiated communications
    |+++++++++>|          | - The DTI sends the IPv6 packet to the TEP.
    |          |--------->| - Y de-encapsulates the IPv4 packet from the
    |          |          |   IPv6 packet then sends the IPv4 packet to
    |          |          |   the destination Z4.

   As  specified in [ND]  RA/RS packets  have a  local link  scope. To
   overpass this,  packets exchanged between the Y6/Y4  router and the
   Dual Stack Host are encapsulated in IPv6 unicast packets.

   When Z responds, the IPv4  packet returns back through Y. Y, having
   cached the association between the  IPv4 and the IPv6 address of X,
   is able to send the IPv4 packet back to X, encapsulating it in IPv6.

2.2 Communication initiated by a IPv4 only node
        DNS
    X6       Y6/Y4      Z4
    |          |          |
    |    < . . . . . . .  | - Z4 asks the DNS for an A RR for "X"
    |    +=+=+>|          | - the DNS only finds a  IPv6  address.  It
    |          |          |   proxies for X6 by sending the  RS request
    |          |          |   that X6 makes in the case of communication 
    |          |          |   described in 2.1.
    |<+=+=+=+=+|          | - Y6/Y4 router  allocates a  temporary IPv4
    |          |          |   address, sends it with a RA  to the
    |          |          |   X6 node and caches the association.
    |    <+=+=+|          | - Y6/Y4 router sends a  dynamic  update  to
    |          |          |   DNS with X6 IPv4 temporary address.
    |   . . . . . . . . > | - DNS answers the A RR to Z4
    |          |<---------| - Z4 can now send its packets to X6 through
    |          |          |   Y6/Y4 router that's ready to  encapsulate
    |          |          |   them.
    |<+++++++++|          | - Y6/Y4 router  encapsulates  IPv4  packets
    |          |          |   into IPv6 for delivery to X6.
    |+++++++++>|          | - When  Y6  answers  Z4, its  DTI sends the
    |          |          |   IPv6 packets to the TEP.
    |          |--------->| - Y de-encapsulate the IPv4 packet from the
    |          |          |   IPv6 packet then sends the IPv4 packet to
    |          |          |   the destination Z4.

    Because DNS just proxies to Y6/Y4 router a request for a temporary
    IPv4 address as issued by  X6, the case of communication initiated
    by a IPv4 only nodes is managed in exactly the same way it is when
    initiated by a Dual Stack Node.

2.3 Tunneling of ND messages

   As specified in [ND] RA/RS ICMP packets have a local link scope. To
   overpass this, packets exchanged  between Y6/Y4 router and the Dual
   Stack Host are encapsulated in IPv6 unicast packets.

   X6        Y6/Y4
    |          |
    |+=+=+=+=+>| - RS packet encapsulated in IPv6 unicast packet.
    |          |   IPv6 unicast packet fields:
    |          |   Sender address: The IPv6 unicast address  of
    |          |      the interface of X6 that can be routed to Y6/Y4.
    |          |   Destination address:  The IPv6 unicast
    |          |      address of Y6/Y4 that can be routed from X6.
    |          |   Payload:  The  RS  packet. (See chapter 3.1 for its
    |          |      detailed format).
    |          |
    |<+=+=+=+=+| - RA packet encapsulated in IPv6 unicast packet.
    |          |   IPv6 unicast packet fields:
    |          |   Sender address: The  IPv6 unicast  address
    |          |        of Y6/Y4 that can be routed to X6.
    |          |   Destination address: The IPv6 unicast address
    |          |        interface of X6 that can be routed from Y6/Y4.
    |          |   Payload: The RA packet. (See  chapter  3.2  for its
    |          |        detailed format).

3. Format of new ND messages
  3.1 RS for IPv4 address solicitation [ borrowed from RFC 2461]

The present draft specifies a new option called "DSH mapping request".

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type      |    Length     |         Reserved  MBZ         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     +                                                               +
     |                                                               |
     +                DSH IPv6 address                               +
     |                                                               |
     +                                                               +
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    IP Fields:

       Source Address
                      The IPv6 address of the interface of the X6 node  

       Destination Address
                      Typically the all-routers multicast address.

       Hop Limit      255

       Authentication Header
                      If   a   Security    Association   for   the   IP
                      Authentication Header  exists between  the sender
                      and  the destination  address,  then  the  sender
                      SHOULD include this header.

    ICMP Fields:

       Type           133

       Code           0

       Checksum       The ICMP checksum.  See [ICMPv6].

       Reserved       This field is unused.  It MUST be initialized to
                      zero by  the sender and  MUST be ignored  by the
                      receiver.

    Option Fields:

       Type           XX (TBD)

       Length         128 bits

       DSH IPv6 address
                     The  IPv6 address  of  the X6  host requesting  a
                     temporary IPv4  address. If DSH  has several IPv6
                     address, the  one that  can be routed  from Y6/Y4
                     MUST be used.

  3.2 RA for IPv4 address allocation [borrowed from RFC2461]

   The  present  draft specifies  a  new  option  called "DSTM",  that
   routers send  out in  a Router Advertisement  message. To  ease the
   management of this option, the document also specifies a "D" bit in
   the ICMP header of the  RA messages indicating that the router acts
   as  a  DSTM border  gateway.  Routers MUST  send  this  RA only  on
   response  to  a  Router   Solicitation  with  option  "DSH  mapping
   request".

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type      |     Code      |          Checksum             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Cur Hop Limit |M|O|H|D|  Res. |       Router Lifetime         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         Reachable Time                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          Retrans Timer                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Options ...
     +-+-+-+-+-+-+-+-+-+-+-+-

   IP Fields:
      Source Address
                     MUST  be the link-local  address assigned  to the
                     interface from which this message is sent.

      Destination Address
                     Typically  the  source  address  of  an  invoking
                     Router Solicitation.  This is the Ipv6 address of
                     the DSH sent in the triggering RS packet.

      Hop Limit      255

      Authentication Header
                     If   a   Security    Association   for   the   IP
                     Authentication  Header exists between  the sender
                     and  the  destination  address, then  the  sender
                     SHOULD include this header.

   ICMP Fields:
      Type           134

      Code           0

      Checksum       The ICMP checksum.  See [ICMPv6].

      Cur Hop Limit  8-bit unsigned  integer.  The default  value that
                     should be placed in the Hop Count field of the IP
                     header for outgoing IP  packets.  A value of zero
                     means unspecified (by this router).

      M              1-bit "Managed address configuration" flag.  When
                     set,   hosts  use  the   administered  (stateful)
                     protocol   for   address   autoconfiguration   in
                     addition  to any  addresses  autoconfigured using
                     stateless address  autoconfiguration.  The use of
                     this flag is described in [ADDRCONF].

      O              1-bit "Other  stateful configuration" flag.  When
                     set,   hosts  use  the   administered  (stateful)
                     protocol    for   autoconfiguration    of   other
                     (non-address) information.  The  use of this flag
                     is described in [ADDRCONF].

      H              According to draft-ietf-mobileip-ipv6-14.txt, the
                     Home Agent (H) bit is  set to value 1 in a Router
                     Advertisement to indicate that the router sending
                     this Router advertisement  is also functioning as
                     a Mobile  IP home agent  on this link.  Else this
                     bit MUST be set to 0

      D              The  bit D is set to 1 to indicate  in  a  Router
                     Advertisement that the router sending this router
                     advertisement  is  also  functioning  as  a  DSTM
                     border gateway. Else this bit MUST be set to 0.

      Res            A 4-bit unused field.   It MUST be initialized to
                     zero  by the sender  and MUST  be ignored  by the
                     receiver.

      Router Lifetime
                     16-bit unsigned integer.  The lifetime associated
                     with the default router in units of seconds.  The
                     maximum  value  corresponds  to  18.2  hours.   A
                     Lifetime of 0 indicates  that the router is not a
                     default  router  and  SHOULD  NOT appear  on  the
                     default router list.  The Router Lifetime applies
                     only  to  the router's  usefulness  as a  default
                     router;   it  does   not  apply   to  information
                     contained  in other  message  fields or  options.
                     Options   that  need   time   limits  for   their
                     information include their own lifetime fields.

      Reachable Time
		     32-bit   unsigned    integer.    The   time,   in
                     milliseconds, that  a node assumes  a neighbor is
                     reachable  after having  received  a reachability
                     confirmation.      Used    by     the    Neighbor
                     Unreachability  Detection algorithm.  A  value of
                     zero means unspecified (by this router).

      Retrans Timer
		     32-bit   unsigned    integer.    The   time,   in
                     milliseconds,   between   retransmitted  Neighbor
                     Solicitation    messages.    Used    by   address
                     resolution   and   the  Neighbor   Unreachability
                     Detection  algorithm   A  value  of   zero  means
                     unspecified (by this router).

   As possible in [ND], this draft proposes a new option called "DSTM".

   Format of the "DSTM" option :

   This document  proposes to specify a  new option field  to hold the
   IPv4  temporary address associated  to the  requesting DSH  and the
   IPv6 address  of the  TEP  that  can  be  different  from the  DSTM
   gateway.

   The format of the DSTM option is as follows:

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type      |    Length     |         Reserved MBZ          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         Valid Lifetime                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       Preferred Lifetime                      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          IPv4 address                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     +                                                               +
     |                           IPv6 address                        |
     +                                                               +
     |                                                               |
     +                                                               +
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Type	     (TBD)
     Length          8-bit unsigned integer.  The length of the option
                     (including the type and length fields) in units of
                     8 octets. The value of 4 is mandatory.  Nodes MUST
                     silently discard an ND packet that contains a DSTM
                     option with length different from 4.

     Valid Lifetime  32-bit unsigned  integer.  The length  of time in
                     seconds (relative to the time the packet is sent)
                     that the  IPv4 and  IPv6 addresses are  valid for
                     the purpose of the  DSTM association.  A value of
                     all one bits (0xffffffff) represents infinity.

     Preferred Lifetime
                     32-bit unsigned  integer.  The length  of time in
                     seconds (relative to the time the packet is sent)
                     that the IPv4 and IPv6 addresses are prefered for
                     the purpose of the  DSTM association.  A value of
                     all one bits (0xffffffff) represents infinity.

     IPv4 address:   The temporarily IPv4 address allocated to the DSH
                     by the DSTM border gateway.

     IPv6 address:   The address of  the TEP that will be  used by the
		     DSH. This address  is generally the DSTM border
		     gateway, but MAY be different.

   Since RA  packets send  by Y6/Y4 to  X6 are encapsulated  into IPv6
   packets, the  standard MTU  rules apply. There  is no need  to send
   multiple fragments of RA packet.

3.3 Request of Dual Stack Node to renew the lease

  Before expiration of an initial lease, the node just send a "normal"
  RS to IPv6/V4 router. It's the responsibility of the router to issue
  a new lease  with a "normal" RA with a new  duration. The router MAY
  use an exponential allocation duration to limit the RS/RA traffic.

4. Security issues

   By  the  virtue  of   authentication  headers  in  RA/RS  messages,
   communication in the IPv6  network are safe. Nevertheless, there is
   a risk of deny of service if a malicious IPv4 node initiates lot of
   connections to IPv6 node. This risk is mitigate by the reuse of the
   same  temporary  IPv4  address  by   the  IPv6  node  for  all  its
   simultaneous   communications  with  several   IPv4  nodes.  To  be
   successful such  an attack  must be conducted by a single IPv4 node
   against several  different IPv6 nodes.  This can be avoided  by the
   DSTM gateway that MAY limit  the number of association for a single
   IPv4 host.

5. Conclusion

   We  showed that  when  collocating  the DSTM  server  in the  Y6/Y4
   router,  we   end  up  with   a  simple  symmetric   mechanism  for
   communications issued from IPv4 only  node or from Y6/Y4 Dual Stack
   Node. In  using RA/RS messages we  do not introduce  huge burden on
   the  router or  on  the  IPv6 node.   This  simple mechanism,  when
   implemented in  Y6/Y4 router and IPv6  node, will make  DSTM a very
   simple  to  deploy  and  to  operate,  general  purpose  transition
   mechanism.

6. References

   [DSTM] Jim  Bound, Laurent  Toutain, Francis Dupont,  Hossam Afifi,
   Alain   Durand,   "Dual   Stack   Transition   Mechanism   (DSTM)",
   <draft-ietf-ngtrans-dstm-04.txt>, January 2001, Work in Progress.

   [ND] Narten, Nordmark, Simpson. Neighbor Discovery for IP Version 6
   (IPv6). RFC 2461, December 1998.

   [ADDRCONF] Thomson, S and  T. Narten IPv6 Address Autoconfiguration
   RFC 2462, December 1998.

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

   [IPv6] S Deering and R  Hinden " Internet Protocol Version 6 (IPv6)
   Specification " RFC 2460, December 1998.

   [MOBV6]  David B.  Johnson, Charles  Perkins, "Mobility  Support in
   IPv6"   <draft-ietf-mobileip-ipv6-14.txt>,  July   2000,   Work  in
   Progress.

Author's Address

     Philippe Bereski
     Alcatel
     route de Nozay
     91461 Marcoussis
     France
     (+33) 16963 4436
     [email-masked]

     Gilles Diribarne
     Alcatel
     route de Nozay
     91461 Marcoussis
     France
     (+33) 16963 4645
     [email-masked]

     Damien Galand
     Alcatel
     route de Nozay
     91461 Marcoussis
     France
     (+33) 16963 4184
     [email-masked]

Copyright Notice

     Placeholder for ISOC copyright.