Re: IPv6 networking: Bad news for small biz

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

 



In message <8155FD1BB2ABCD40AC6F8149BBE997E003E0682362F8@sdcexchms.netstarnetwo
rks.com>, Greg Daley writes:
> Hi Mark,=20
> =20
> > > But of course, I'm always delighted to hear your opinions.  Is =3D
> > > renumbering *really* that big of a deal?  I suppose multihoming is the
> > > =3D bigger, more serious concern - that's the one we see no viable
> > > solution =3D but NAT for, given small site constraints and aggregation.
> >=20
> > Total hogwash.  Add a bit of source address based routing within the
> > enterprise so that you hit the right exit routers for the source address =
> being
> > used.  Tag route entries with valid source prefixes.
> > Add redirect based on source address signaling.
> 
> Source based routing is a pain to maintain and to troubleshoot!

Why is a pain to maintain?  Because no one has written a routing
protocol to exchange the necessary information?  Routing engines
havn't been updated to use this information?  The border routers add
source address prefix tags to the routes they advertise internally
for the prefixes they have been delegated by the ISP.

This destination with these source addresses goes to this next hop.

If you have PI then "these source addresses" becomes ::/0 in most cases.

> In business-land I have had to pull out cruddy, unmaintainable solutions wh=
> ich modify normal routing behaviour and sit undocumented in various busines=
> ses.  This is salient because some of the businesses are small, or started =
> small.

So rather than make a maintainable solution you throw out the idea.
 
> Please don't suggest strange addressing or routing tricks, and I will not s=
> uggest strange DNS tricks ;-)
> 
> I would be OK if there was a straightforward RPF-like check which could be =
> applied at edge routers to ensure that packets exit via the correct ISP, bu=
> t my customers' routing tables are destination based, like 99% of the Inter=
> net.

And they still will be destination based with source addresses use
to differentiate between different entries.

> Greg Daley
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@xxxxxxx


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]