Hello all,
I'm investigating how to setup multihoming for IPv6 over two DSL lines
(different ISPs), and I wanted to see if this wheel has already been
invented. Has anyone already set this up or tested it ?
In my research into the proposed solutions I came across this document
"IEEE Communications Surveys - 2nd Quarter 2006, Volume 8, No. 2"
(http://www.shim6.org/path-to-mh.pdf) which seems quite thorough. It
compares routing methods, middle-box methods, and host-centric methods.
It mentions "During the last years, the IETF has made several explicit
or implicit architectural decisions regarding IPv6 multihoming. The main
decision is to go down the path of developing the host-centric
approaches" as well as "Host-centric multihoming, the approach promoted
by the IETF for IPv6 multihoming, [...]". After the comparison of all
host-centric methods it adds " [...], the IETF has decided by the end of
2004 to foster the SHIM approach."
This approach looks interesting to me after all the comparisons, though
I'm less familiar with it. I'm interested to hear your real-world
experiences on this topic.
Thanks,
Daniel
why would you do that for?
how many ip addresses do you have ?
have you thought about taking a Cisco training course?
Hi Daniel,
all IPv6 multihoming ideas are very theoretical today. None of them
is ready to use. Shim6 looks very good, but it requires support on both
a client and a server side. As you can guess, there is only experimental
support for some operating systems. Microsoft and Apple doesn't support it.
A one possible solution I have found is based on a network prefix
translation (NPTv6 draft-mrw-nat66-12). Using
NPTv6 you can do multihoming that is very similar to multihoming based
on IPv4 NAT.
I haven't found any commercial product that supports it, but you can use
an implementation for Linux (map66
MAP66 download | SourceForge.net). Assembling map66 with some
other scripts (to detect link failure) you can have what are you looking
for.
have you thought about taking a Cisco training course?
I wonder if that kind of knowledge can be learned in any Cisco course
today. I don't think so.
Tomas
Hi Daniel,
all IPv6 multihoming ideas are very theoretical today. None of them
is ready to use. Shim6 looks very good, but it requires support on both
a client and a server side. As you can guess, there is only experimental
support for some operating systems. Microsoft and Apple doesn't support it.
Well, BGP multihoming works today quite well. It's no different from IPv4
and is a perfectly viable technology.
A one possible solution I have found is based on a network prefix
translation (NPTv6 draft-mrw-nat66-12). Using
NPTv6 you can do multihoming that is very similar to multihoming based
on IPv4 NAT.
You can also use thumb cuffs to suspend yourself from a rafter, but, I don't
recommend it unless you are into pain.
Owen
It doesn't exist in practice; real world is BGP multihoming. Everything
else is still just an academic exercise.
~Seth
When you talking about "two DSL lines", I assume this is mainly for
office / residential environment to have redundancy and/or increase
uplink availability.
In this environment, BGP exchanges with uplink ISPs for multihoming
usually is not an option. One reason maybe cost, another reason maybe
ISP doesn't like to setup BGP with a DSL customer. At least in my
case, reason #2 always prevent my customers to setup BGP with uplink
ISPs.
As Seth pointed out SHIM6 is still an academic exercise, my
experiences to resolve this needs at this moment is leveraging NAT66,
as what we did in IPv4 world. I use FreeBSD+PF and Juniper
NetScreen/SSG to do NAT66 in several different locations, and they all
works as expected so far.
Some people don't like NAT especially NAT66, but to be realistic that
does work, and works well in terms of providing redundancy over two
DSL lines for office / residential needs.
Although i generally hate NAT, multihoming must be the only (or at least the most important) reason why NAT66 has to be standardized.
Otherwise some kind of routing must be implemented on hosts.
ote:
>
>> I'm investigating how to setup multihoming for IPv6 over two DSL lines
>> (different ISPs), and I wanted to see if this wheel has already been
>> invented. Has anyone already set this up or tested it ?
>>
> When you talking about "two DSL lines", I assume this is mainly for
> office / residential environment to have redundancy and/or increase
> uplink availability.
>
> In this environment, BGP exchanges with uplink ISPs for multihoming
> usually is not an option. One reason maybe cost, another reason maybe
> ISP doesn't like to setup BGP with a DSL customer. At least in my
> case, reason #2 always prevent my customers to setup BGP with uplink
> ISPs.
>
> As Seth pointed out SHIM6 is still an academic exercise, my
> experiences to resolve this needs at this moment is leveraging NAT66,
> as what we did in IPv4 world. I use FreeBSD+PF and Juniper
> NetScreen/SSG to do NAT66 in several different locations, and they all
> works as expected so far.
>
> Some people don't like NAT especially NAT66, but to be realistic that
> does work, and works well in terms of providing redundancy over two
> DSL lines for office / residential needs.
>
> --
> Michel~
>
>
>
Although i generally hate NAT, multihoming must be the only (or at least
the most important) reason why NAT66 has to be standardized.
Otherwise some kind of routing must be implemented on hosts.
And what's wrong with routing on hosts? If a router advertises a
prefix it should know where to send traffic that originates from
that prefix. You just choose the next hop by looking at which
routers are advertising the prefix for the source address for this
packet and choosing between them. It's a touch more state to be
kept with every address. It would also be useful for filtering out
rouge RAs. You look at the address you learnt the prefix from then
filter out that router / prefix.
Some kind of routing is already implemented on hosts.
Joe
I'm investigating how to setup multihoming for IPv6 over two DSL lines
(different ISPs), and I wanted to see if this wheel has already been
invented. Has anyone already set this up or tested it ?
When you talking about "two DSL lines", I assume this is mainly for
office / residential environment to have redundancy and/or increase
uplink availability.
In this environment, BGP exchanges with uplink ISPs for multihoming
usually is not an option. One reason maybe cost, another reason maybe
ISP doesn't like to setup BGP with a DSL customer. At least in my
case, reason #2 always prevent my customers to setup BGP with uplink
ISPs.
As Seth pointed out SHIM6 is still an academic exercise, my
experiences to resolve this needs at this moment is leveraging NAT66,
as what we did in IPv4 world. I use FreeBSD+PF and Juniper
NetScreen/SSG to do NAT66 in several different locations, and they all
works as expected so far.
Some people don't like NAT especially NAT66, but to be realistic that
does work, and works well in terms of providing redundancy over two
DSL lines for office / residential needs.
--
Michel~
Although i generally hate NAT, multihoming must be the only (or at least the most important) reason why NAT66 has to be standardized.
Otherwise some kind of routing must be implemented on hosts.
There is no need for NAT in order to multiple-home. BGP is every bit as effective and much simpler.
Owen
I know a lot of small businesses with one FiOS link and one Comcast
link and I don't think they're going to be able to do BGP. Their
providers won't do it and their prem equipment doesn't support it and
the local IT person doesn't have the know-how to do it. I know that
the typical NANOG member isn't in this category, but this is a
use-case that is very common and outnumbers NANOG members.
Tom
your mobile phone is multihomed, as is this laptop I'm typing on.
There is no need for NAT in order to multiple-home. BGP is every bit as effective and much simpler.
I know a lot of small businesses with one FiOS link and one Comcast
link and I don't think they're going to be able to do BGP. Their
providers won't do it and their prem equipment doesn't support it and
the local IT person doesn't have the know-how to do it. I know that
the typical NANOG member isn't in this category, but this is a
use-case that is very common and outnumbers NANOG members.
building a cpe that can do something useful with two ip addresses and
two default routes to two consumer isps isn't really that hard, had a
cisco 2500 circa 1995 that did dial on demand for backup... heck, today
you can get a cradlepoint with 3 x 3g/4g wireless cards attached.
Otherwise some kind of routing must be implemented on hosts.
Some kind of routing is already implemented on hosts.
honto???
your mobile phone is multihomed, as is this laptop I'm typing on.
routing != multihomed
it's not an autonomous system it's embedded inside one or more of them...
it most definitely makes a forwarding decision which in this case also
requires address selection.
try rfc 1812
A router connects to two or more logical interfaces, represented by
IP subnets or unnumbered point to point lines (discussed in section
[2.2.7]). Thus, it has at least one physical interface. Forwarding
an IP datagram generally requires the router to choose the address
and relevant interface of the next-hop router or (for the final hop)
the destination host. This choice, called relaying or forwarding
depends upon a route database within the router. The route database
is also called a routing table or forwarding table. The term
"router" derives from the process of building this route database;
routing protocols and configuration interact in a process called
routing.
(I think you meant honto desu ka??).
hai. Honto desu.
Owen
Many of my hosts have more than one interface and will forward packets received on one
to hosts connected on others.
That's routing.
Next?
Owen