[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Same global address on Multiple Interface of an IP6 node



> Redundancy.  If one interface goes down, traffic will automatically switch 
> to the another interface without disrupting existing connections.

I think there is some confusion between the conceptual descrption of IPv6
(using terms like "interface" and "link" as per RFC 2460) and how one
can actually build a system using e.g. Ethernet cards.

At the conceptual level a global unicast address can only be assigned
to one interface in the Internet.
But since the "interface" is an abstraction that is provided to IP
there is nothing to prevent an implementation whicb uses multiple Ethernet
cards attached to the same or different Ethernet switches as long as this
is transparent to IP. An example of such an approach is IEEE 802.3ad which 
provides what looks like a single aggregate, with a single MAC address,
on top of multiple Ethernet cards. (If you read the IEEE 802 specs be aware
that the definition of "link" is subtle but completely different between
those specs and RFC 2460.)

So far so good. There might be cases where you want to use a slightly different
implementation technique where the abstraction has multiple MAC addresses; for
instance one per participating Ethernet card. There isn't much in the RFCs to
guide such an approach, but as long as it interoperates with other
implementations it would be ok. There is a subtle part of RFC 2461 which tries
to make this easier - the ability to omit the source link-layer address option
in router advertisements be able build routers which give different link-layer
addresses (for the same IP address) to different hosts using unicast neighbor
advertisements. But details on how to build such a "load balance across
multiple MAC addresses" thing for a router or for a host are left as a detail
for the reader :-)

But if you are only concerned about redundancy and not load spreading across
the Ethernet cards life is probably simpler.

  Erik

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------