One document matched: draft-armitage-ipatm-ipv6mc-00.txt

Internet-Draft                                      Grenville Armitage
                                                              Bellcore
                                                       June 20th, 1995


                        IPv6 multicast over ATM
                  <draft-armitage-ipatm-ipv6mc-00.txt>


Status of this Memo

      [This is a first cut at throwing together some section headings
         and sketching out the major points that an IPv6 over ATM
        implementor would want to know. Further input appreciated.]

   This document was submitted to the IETF IP over ATM WG. Publication
   of this document does not imply acceptance by the IP over ATM WG of
   any ideas expressed within.  Comments should be submitted to the ip-
   atm@matmos.hpl.hp.com mailing list.

   Distribution of this memo is unlimited.

   This memo is an internet draft. 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. Internet Drafts may be updated, replaced, or obsoleted by
   other documents at any time. It is not appropriate to use Internet
   Drafts as reference material or to cite them other than as a "working
   draft" or "work in progress".

   To learn the current status of any Internet-Draft, please check the
   "lid-abstracts.txt" listing contained in the Internet-Drafts shadow
   directories on ds.internic.net (US East Coast), nic.nordu.net
   (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
   Rim).

Abstract

   The Internet Draft draft-ietf-ipatm-ipmc-05.txt ("Support for
   Multicast over UNI 3.1 based ATM Networks") describes a mechanism for
   handling IP multicast over ATM. Whilst the architecture is intended
   to support multiple protocols such as IP, IPX, AppleTalk, etc, the
   current examples apply only to IPv4 environments.  This document
   describes the specific encodings that should be used when running
   IPv6 over ATM. It is expected that some of this text will influence



Armitage              Expires December 20th, 1995                [Page 1]

Internet Draft          IPv6 multicast over ATM          June 20th, 1995


   the revision of draft-ietf-ipatm-ipmc-05.txt or become a separate
   companion document in its own right.


1. Introduction.

   The examples given in Internet Draft draft-ietf-ipatm-ipmc-05.txt [1]
   ("Support for Multicast over UNI 3.1 based ATM Networks") are
   focussed specifically on running IPv4 over ATM. The next generation
   of IP (IPng or IPv6 [2]) is theoretically a simple version change
   from IPv4. However, recent events in the IPng working group have led
   to the decision that interworking between IPv6 and old IPv4 equipment
   will be improved if IPv6 can be treated as a new protocol at the link
   layer.

   A new Ethertype of 0x86DD has been allocated to IPv6 [3].  As a
   consequence, IPv6 will be treated as a separate link level protocol
   by the Multicast Address Resolution Server (MARS) described in [1].
   This document begins to specify exactly where this ethertype shows up
   (e.g. how IPv4 and IPv6 over ATM implementations respectively encode
   their MARS messages, and modifications to the LLC/SNAP encapsulation
   applied to IP packets).


2. Changes to values in MARS messages.

   As no change has occured to the MARS/ATMARP protocol the
   encapsulation of MARS messages remains as shown in section 4 of [1]:

      [0xAA-AA-03][0x00-00-00][0x08-06][MARS message]
          (LLC)       (OUI)     (PID)

   The ar$hrd field in every MARS messages remains 19.

   However, the ar$pro field of every MARS message MUST be set to 0x86DD
   for MARS messages relating to IPv6 multicast groups, and 0x800 for
   MARS messages relating to IPv4 multicast groups.

   When carrying IPv6 addresses the ar$spln and ar$tpln fields are
   either 0 (for null or non-existent information) or 16 (for the full
   IPv6 address).

   The special 'registration' address used by hosts and MCSs to register
   as members of ClusterControlVC and ServerControlVC is now 16 bytes of
   zero (the <min,max> pair will be 32 bytes of zero).  This does not
   represent a multicast address under IPv6.





Armitage              Expires December 20th, 1995                [Page 2]

Internet Draft          IPv6 multicast over ATM          June 20th, 1995


3. Encapsulation of IPv6 multicast packets.

   Following the RFC1483 scheme, unicasted IPv6 packets will be
   encapsulated as:

      [0xAA-AA-03][0x00-00-00][0x86DD][IPv6 packet]
          (LLC)       (OUI)     (PID)

   Section 5.5 of [1] identifies a limitation of this encapsulation when
   ATM multicasting occurs using multicast servers.  An extended
   encapsulation is likely to be adopted at the July 1995 meeting of the
   IP-ATM working group. This can be trivially applied to IPv6 multicast
   traffic.

   Consider, for example, that the encapsulation for multicasting used a
   codepoint from the IANA OUI and encoded the ethertype within the new
   payload [4]. The encoding for IPv4 would be:

      [0xAA-AA-03][0x00-00-5E][New PID][2 byte CMI][0x800][IPv4 packet]
          (LLC)       (OUI)     (PID)  |<---      new payload     --->|

   The corresponding encoding for IPv6 would be:

      [0xAA-AA-03][0x00-00-5E][New PID][2 byte CMI][0x86DD][IPv6 packet]
          (LLC)       (OUI)     (PID)  |<---      new payload      --->|

   (The actual extended encapsulation has not yet been defined by the
   ip-atm WG at this time. The above encoding is purely by way of
   illustrative example.)


4. Routers and promiscuous listening on 'all' groups.

   As described in section 9 of [1] for IPv4, routers should perform a
   block MARS_JOIN for the range of IPv6 multicast addresses they need
   each ATM interface (whether logical or physical) to listen on.

   Other issues on this topic are for further study (e.g. the use of
   MARS_GROUPLIST_REQUEST to replace ICMPv6 messages used to determine
   what groups have members on the subnet).


5. Questions of a wider nature.

   This section is not intended to go into a rewrite of [1]. It exists
   simply to re-assure people studying IPv6 over ATM that they are not
   imagining things if they perceive a certain amount of redundancy in
   running Neighbour Discovery using IP multicasting of ICMPv6 packets



Armitage              Expires December 20th, 1995                [Page 3]

Internet Draft          IPv6 multicast over ATM          June 20th, 1995


   in an ATM environment.

   It is interesting to note that ATM services offered by UNI 3.1 do not
   naturally provide us with Ethernet-like link level multicast support
   (hence the need for [1]). Multicasting must be emulated, and this
   emulation presupposes the existence of knowledge about the other
   ATM-attached IP hosts in your subnet. In [1] the MARS has a fairly
   good idea of what IP endpoints can be associated with what ATM
   endpoint addresses. However, Neighbour Discovery at the IP level uses
   link level multicasting to transmit ICMPv6 packets, which will enable
   the discovery of link-layer/IP-layer mappings.

   If you are implementing a Classical IP/ATM model, your ARP Server
   probably already knows this information (and is most likely
   implemented by the same piece of software providing you with your
   MARS service that enables the disovery messages to be multicasted).

   It remains for further study on what sort of short cuts an IP/ATM
   interface might make when faced with neighbour discovery requests.
   Perhaps trapping multicasted ICMPv6 General Solicitations and turning
   them into ATMARP requests (or MARS requests, if you're experimenting
   with MARS support for unicast mappings [5]).  The reply would then be
   used by the IP/ATM driver to fake the reception of a General
   Advertisement containing the information needed by the local IPv6
   layer.


Security Consideration

   Security considerations are not addressed in this memo.

Author's address

   Grenville Armitage
   Internetworking Research Group,
   Bellcore.
   445 South Street
   Morristown, NJ, 07960-6438
   USA

   Email: gja@thumper.bellcore.com


References.

   [1] G.J. Armitage, "Support for Multicast over UNI 3.1 based ATM
   Networks", INTERNET DRAFT, IP-over-ATM WG, June 1995.




Armitage              Expires December 20th, 1995                [Page 4]

Internet Draft          IPv6 multicast over ATM          June 20th, 1995


   [2] R. Hinden, "IP Next Generation (IPng)",
   http://playground.sun.com/pub/ipng/html/ipng-main.html

   [3] S. Deering, email to ipng@sunroof.Eng.Sun.COM, Friday 16 Jun
   1995.

   [4] B. Gleeson, G. Armitage, "Issues surrounding a new encapsulation
   for IP over ATM.", INTERNET DRAFT, IP-over-ATM WG, May 1995.

   [5] G.J. Armitage, " Using the MARS to support IP Unicast over ATM",
   INTERNET DRAFT, IP-over-ATM WG, June 1995.

   Useful URL:

   ftp://thumper.bellcore.com/pub/gja/www/i-drafts.html




































Armitage              Expires December 20th, 1995                [Page 5]