Internet DRAFT - draft-williams-ipvlx-ipbridging

draft-williams-ipvlx-ipbridging





Network Working Group                                        A. Williams
Internet-Draft                                                     NICTA
Expires: January 18, 2005                                  July 20, 2004


                          Bridging IP at Layer-3
                    draft-williams-ipvlx-ipbridging-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 January 18, 2005.

Copyright Notice

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

Abstract

    Joining incompatible links together as an IP subnet by bridging IP
    packets at Layer-3 is an attractive goal.  Several challenges that
    need to be addressed before IPbridging becomes a reality are listed
    in this document.











Williams                Expires January 18, 2005                [Page 1]


Internet-Draft           Bridging IP at Layer-3                July 2004


Table of Contents

    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
    2.  Complications with IPbridging  . . . . . . . . . . . . . . . .  4
    3.  IPbridging and Rbridge . . . . . . . . . . . . . . . . . . . .  6
    4.  Other Notes  . . . . . . . . . . . . . . . . . . . . . . . . .  7
      4.1   IPv4 DHCP  . . . . . . . . . . . . . . . . . . . . . . . .  7
      4.2   Routing Protocol Requirements  . . . . . . . . . . . . . .  7
        4.2.1   Unicast  . . . . . . . . . . . . . . . . . . . . . . .  7
        4.2.2   Multicast  . . . . . . . . . . . . . . . . . . . . . .  7
      4.3   IPv6 ND-proxy  . . . . . . . . . . . . . . . . . . . . . .  8
      4.4   IPv6 Unique Local Addressing and IPbridging  . . . . . . .  8
    5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
    6.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
        Author's Address . . . . . . . . . . . . . . . . . . . . . . .  9
        Intellectual Property and Copyright Statements . . . . . . . . 10



































Williams                Expires January 18, 2005                [Page 2]


Internet-Draft           Bridging IP at Layer-3                July 2004


1.  Introduction

    IP protocols are widely used to build networks from multiple links of
    differing types by assigning IP address ranges to each link and
    connecting links with an IP router.  Assignment of address ranges to
    links is usually a manual process unsuited to plug-and-play
    networking.  Automatic assignment of address ranges to links is
    possible but proposals to date have suffered from inefficient use of
    address space, link renumbering when network topolgoy changes and
    host renumbering when changing attachment point.

    802-style LAN bridging provides a good example of plug and play
    networking, however it too has some drawbacks.  Layer-2 bridging
    cannot be used between links with different L2 address types,
    problems arise bridging links with the same L2 address type but
    differing MTUs and multicast addressing semantics can differ between
    links with the same L2 address type.  Furthermore, L2 spanning trees
    result in inefficient paths between end nodes and concentrates
    traffic on a subset of the available links.  See [Deering-email] and
    [Rbridge] for more details.

    A device connecting several links in an IP subnet together by
    bridging IP packets at Layer 3 (an IPbridge) could combine the best
    of both worlds and achieve plug and play operation over links that
    cannot be bridged at Layer-2.  IPbridges would behave as IP routers
    with a host route for each IP device in the subnet.  IPbridges could
    use a more sophisticated routing protocol than spanning tree
    resulting in more efficient paths and spreading of traffic over the
    available links.






















Williams                Expires January 18, 2005                [Page 3]


Internet-Draft           Bridging IP at Layer-3                July 2004


2.  Complications with IPbridging

    Although IPbridging appears superficially similar to LAN bridging
    there are a number of complicating differences:

       IP address bootstrapping:
          IPbridges carrying out the normal functions of an IP router
          (e.g.  fragmenting packets, decrementing the IP TTL, issuing
          redirects) will need an IP address to use as a source address
          in ICMP messages.  However, IP addresses are not pre-configured
          into devices like EUI-48 MAC addresses and IPbridges must
          somehow acquire an IP address before sending ICMP messages.

          Host autoconfiguration protocols are also hard to handle with
          vanilla IPbridging because the bootstrapping device does not
          yet have an IP address associated with it that is usable by an
          IPbridge as a destination.  In a LAN, link specific information
          like MAC addresses are usually used to deliver the
          autoconfiguration protocol messages to the bootstrapping
          device.

       IP address to link address mapping:
          Final delivery of an IP packet to an end device often requires
          mapping the destination IP address to a link layer address.
          This mapping is link specific and is not required in LAN
          bridging because the link layer address is assumed to be the
          same.

       Discovery and use of exit routers:
          IP networks are usually connected to other IP networks and to
          the Internet via routers.  Unlike LANs, where every destination
          is assumed to be directly reachable, IP networks distinguish
          between directly reachable destinations and destinations that
          must be reached through a router.  IPbridges forwarding packets
          to destinations outside the local IP subnet need to decide
          which exit router should be used.  Protocols like DHCP pass
          default router information to the client -- should IPbridges
          honour that or should they discover all available exit routers
          and choose?  Should clients using router discovery see
          IPbridges or exit routers?  Should redirects from exit routers
          affect routing between IPbridges or only the clients?

       Protocol semantics:
          Various IP protocols (e.g.  IPv6 Neighbor Discovery, DHCP,
          IGMP/MLD) assume that certain types of broadcast and multicast
          messages are not forwarded by IP routers and that they are
          delivered to all instances of a particular network service
          within a subnet.  Many of these protocols set and check the IP



Williams                Expires January 18, 2005                [Page 4]


Internet-Draft           Bridging IP at Layer-3                July 2004


          TTL field to ensure that forwarding does not occur or detect
          when it has.  For these protocols, an IPbridge would need to
          proxy services (e.g.  act as a DHCP relay or default router) or
          proxy the required information (e.g.  IGMP/MLD).















































Williams                Expires January 18, 2005                [Page 5]


Internet-Draft           Bridging IP at Layer-3                July 2004


3.  IPbridging and Rbridge

    Rbridge [Rbridge] is an improved system for bridging 802 addressed
    networks.  L2 frames are encapsulated for transport between rbridges
    and decapsulated for transmission onto the destination link.  The
    encapsulation header contains a hop count which is decremented each
    time the packet is forwarded by an Rbridge.  Packets are discarded
    when the hop count reaches zero preventing catastrophic packet
    looping.  Rbridges run a link state routing protocol to exchange end
    node reachability information, to compute optimal network paths and
    to support fast fast recovery after link failure.

    Since a great deal of traffic on 802 networks is IP traffic and since
    IP packets already have a TTL, forwarding IP packets without rbridge
    encapsulation is an attractive optimisation for Rbridges.  In this
    case the Rbridge would behave as an IPbridge and decrement the IP TTL
    when forwarding a packet.

    An Rbridge forwarding bare IP packets is not restricted to pure
    IPbridge operation -- for example, it can make use of the L2
    forwarding information for an destination IP address it does not know
    how to reach.  When an Rbridge is bridging between two incompatible
    links using bare IP packets it is operating as a pure IPbridge.  In
    general, it may make sense for Rbridges using optimised IP forwarding
    to treat some IP traffic as L2 traffic (e.g.  DHCP).


























Williams                Expires January 18, 2005                [Page 6]


Internet-Draft           Bridging IP at Layer-3                July 2004


4.  Other Notes

4.1  IPv4 DHCP

    DHCP, as typically deployed on a bridged 802 network, will not
    operate in an IPbridged network.  There are several issues.  Firstly,
    DHCPDISCOVERs and other messages are sent to a local IPv4 broadcast
    address 255.255.255.255 that should not be forwarded by an IPbridge.
    Secondly, DHCPOFFERs can be unicast to the requesting client using
    the MAC address supplied in the DHCPDISCOVER message.  There has been
    no information before the DHCPOFFER that would allow an IPbridge to
    correctly forward to the requesting client without using L2
    information.

    An alternative is for IPbridges to act as a DHCP relays.  This would
    work however configuration is required.  Configuration information
    for the DHCP relay could be distributed in the routing protocol.

4.2  Routing Protocol Requirements

4.2.1  Unicast

    Most IP routing protocols use an IP address as a router identifer and
    require at least one IP address for communication.  IP addresses for
    communication can be constructed using link-local addressing, however
    router identifiers need to be unique in the routing domain creating a
    potentially circular dependancy on the address allocation mechanism.
    Routing protocols fundamentally assume that router identifiers are
    unique.  If they are not (such as when two networks using an
    automatic router id allocation mechanism are merged), chaos may
    ensue.

    A notable exception is the IS-IS routing protocol which uses a 48-bit
    System ID (commonly a MAC address) and does not use IP for
    communication.

4.2.2  Multicast

    Currently, Rbridge and 802.1 Spanning Tree variants distribute
    multicast over a single spanning tree.  Multicast forwarding in
    Rbridged/IPbridged networks could be made more efficient by
    distributing group membership and multicast source information via
    the link state routing protocol.  This approach was used for MOSPF
    [RFC1584][RFC1585]..  Rbridges may still need to generate IGMP
    packets to build efficient paths through the L2 networks between
    Rbridges.





Williams                Expires January 18, 2005                [Page 7]


Internet-Draft           Bridging IP at Layer-3                July 2004


4.3  IPv6 ND-proxy

    [IPv6-multilink] describes a method for connecting multiple links
    sharing a common IPv6 prefix with routers that perform Neighbor
    Discovery proxying for hosts not connected to the local link.
    Topologies with loops are not supported.

4.4  IPv6 Unique Local Addressing and IPbridging

    [IPv6-ULA] describes a method for randomly generating IPv6 prefixes
    with a high probability of uniqueness providing that the total number
    of generated prefixes is small.  This technique could be used to
    bootstrap IP addressing for IPv6 IPbridging.  TBD: A combination of
    ND-proxy, IPv6-ULA and routing might work, for IPv6..





































Williams                Expires January 18, 2005                [Page 8]


Internet-Draft           Bridging IP at Layer-3                July 2004


5.  Security Considerations

    None.

6  References

    [Deering-email]
               Deering, S., "Four problems with link layer bridging", Oct
               2002.

               http://internet.motlabs.com/pipermail/zerouter/
               2002-October/000029.html

    [IPv6-ULA]
               Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
               Addresses", draft-ietf-ipv6-unique-local-addr-05 (work in
               progress), June 2004.

    [IPv6-multilink]
               Thaler, D. and C. Huitema, "Multi-link Subnet Support in
               IPv6", draft-ietf-ipv6-multilink-subnets-00 (work in
               progress), July 2002.

    [RFC1584]  Moy, J., "Multicast Extensions to OSPF", RFC 1584, March
               1994.

    [RFC1585]  Moy, J., "MOSPF: Analysis and Experience", RFC 1585, March
               1994.

    [Rbridge]  Perlman, R., "RBridges: Transparent Routing",
               draft-perlman-rbridge-00 (work in progress), May 2004.


Author's Address

    Aidan Williams
    National ICT Australia (NICTA)
    Bay 15, Locomotive Workshop
    Australian Technology Park
    Eveleigh, NSW  1430
    Australia

    Phone: +61 2 8374 5558
    EMail: aidan@nicta.com.au
    URI:   http://nicta.com.au/






Williams                Expires January 18, 2005                [Page 9]


Internet-Draft           Bridging IP at Layer-3                July 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



Williams                Expires January 18, 2005               [Page 10]


Internet-Draft           Bridging IP at Layer-3                July 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.











































Williams                Expires January 18, 2005               [Page 11]