Network Working Group                                     Francis Dupont
Internet-Draft                                                     INRIA
Expire in six months                              1997/03/23 17:50:50MET

       Implications of the GSE Addressing Scheme to IPv6 Multicast

                <draft-dupont-ipv6-gse-multicast-00.txt>

. Status of this Memo

   This document 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
   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.''

   To learn the current status of any Internet-Draft, please check the
   1id-abstracts.txt listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa) , nic.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast ), or
   ftp.isi.edu (US West Coast).



. Abstract

   This document presents some implications for the GSE Addressing Scheme
   ([1] draft-ietf-ipngwg-gseaddr-00.txt proposal by Mike O'Dell) on IPv6
   multicast: a new scope for large structures and a clever way to
   compare two addresses for the election of a designated router.


. Introduction

   The GSE Addressing Scheme cuts IPv6 unicast provider-based addresses
   into two 8 octet fields, the first one for routing and the second
   one for an ``end system designator''. The routing part begins with
   a large structure ID.

   The scopes defined by the RFC 1884 (IPv6 Addressing Architecture) for
   multicast addresses in section 2.6 pages 14 and 15 have no value
   between organization-local (8) and global (E) scopes.

   The IGMP version 2 proposal (draft-ietf-idmr-igmp-v2-06.txt) specifies
   an election process for the ``Querier'' multicast router on a physical
   network (this election process is a part of the DVMRP v3 proposal
   (draft-ietf-idmr-dvmrp-v3-04.txt) too): the multicast router with
   the ``lower'' IP address is selected.

. Large Structure Scope

   A new scope for large-structure-local scope with the value C (12) is
   defined. The Address Testing Macro for Basic Socket Interface
   Extensions for IPv6 (draft-ietf-ipngwg-bsd-api-07.txt) is:

       int  IN6_IS_ADDR_MC_LSLOCAL  (const struct in6_addr *);

. Clever Address Comparison

   The ESD field is far more stable than the routing half at the
   beginning of an address and is unique on the link. This document
   defines the way to compare two addresses: only the tail 8 octets
   (the ESD field) MUST be compared. The code for the lower test
   looks like:

        (((x)->s6_addr[8] < (y)->s6_addr[8]) ||
         (((x)->s6_addr[8] == (y)->s6_addr[8]) &&
          (((x)->s6_addr[9] < (y)->s6_addr[9]) ||
           (((x)->s6_addr[9] == (y)->s6_addr[9]) &&
            (((x)->s6_addr[10] < (y)->s6_addr[10]) ||
             (((x)->s6_addr[10] == (y)->s6_addr[10]) &&
              (((x)->s6_addr[11] < (y)->s6_addr[11]) ||
               (((x)->s6_addr[11] == (y)->s6_addr[11]) &&
                (((x)->s6_addr[12] < (y)->s6_addr[12]) ||
                 (((x)->s6_addr[12] == (y)->s6_addr[12]) &&
                  (((x)->s6_addr[13] < (y)->s6_addr[13]) ||
                   (((x)->s6_addr[13] == (y)->s6_addr[13]) &&
                    (((x)->s6_addr[14] < (y)->s6_addr[14]) ||
                     (((x)->s6_addr[14] == (y)->s6_addr[14]) &&
                      ((x)->s6_addr[15] < (y)->s6_addr[15])))))))))))))))

   Obviously one can write far simpler code for a big endian 64 bit
   architecture.

. Security Considerations

   Security considerations are not addressed in this memo.

. Author's address

   Francis Dupont
   INRIA Rocquencourt
   Domaine de Voluceau
   B.P. 105
   78153 Le Chesnay Cedex
   FRANCE

   E-mail: Francis.Dupont@inria.fr