Re: Distributing site-wide RFC 3484 policy

[itojun@itojun.org (Jun-ichiro itojun Hagino)]

> > 	you are talking about a separate story.  the thread is about having
> > 	to run source-address selection between IPv6 addresses with different
> > 	"scope" or reachability.
> 
> I'm very much interested in achieving the following:
> 
> Get both ADSL and cable connectivity from competing providers (or  
> fill in two last 1609 meter technologies of your choice), where each  
> of those connections has a separate gateway attached that doesn't  
> know about the other gateway. Both announce a PA block from the ISP  
> in question using stateless autoconf. My hosts configure with two  
> addresses and two default gateways, and use the appropriate gateway  
> with a given source address. When an application can't connect using  
> one source/dest pair, it tries the others until there is a working  
> connection.

	i would like to name the devices/networks like:

		ISP-A	ISP-B
		  |	  |
		RT-A	RT-B
		  |	  |
		==+=======+== PREFIX-A:0::/64, PREFIX-B:0::/64
		  | ADDR-A/128, ADDR-B/128
		your machine

	now, first of all, you really cannot define/determine what is the
	best combination among the following to reach the destination, X.
	X could be within ISP-A, ISP-B, or totally far end of the planet with
	rather long AS path.  the evaluation would make about "the best"
	combination would make you a god looking from above.  what you can
	do is to pick one and hope.
		use ADDR-A out of PREFIX-A:0::/64 and use RT-A
		use ADDR-A out of PREFIX-A:0::/64 and use RT-B
		use ADDR-B out of PREFIX-B:0::/64 and use RT-A
		use ADDR-B out of PREFIX-B:0::/64 and use RT-B

	next, depending on operating system on your machine, the treatment of
	default router differs.  this is outside of the "source address
	selection".
	- some implementation picks the default route out of RT-A/B at will
	- some implementation do install both RT-A/B as the default gateway
	  but it uses only one of them
	- some implementation tries to perform load-balancing

	moreover, if you set up another link to set up firewall or something,
	you really do not have any idea to pick among RT-A or RT-B.  i have
	been suggesting you to leave it to be handled by routing table among
	routers, and/or configuration between RT-A/RT-B.  it would be seriously 
	painful to make "your machine" know about all the details about your
	network egress points, it does not scale and you will have
	configuration mistakes.

		ISP-A	ISP-B
		  |	  |
		RT-A	RT-B
		  |	  |
		==+=======+== PREFIX-A:0::/64, PREFIX-B:0::/64
		  |
		router
		  |
		==+======= PREFIX-A:1::/64, PREFIX-B:1::/64
		  | ADDR-A/128, ADDR-B/128
		your machine

	if one of/both of ISP practices filtering such as uRPF, you would
	have to narrow down the choices so that you would pick PREFIX-A for
	RT-A (ISP-A), and PREFIX-B for RT-B (ISP-B).  but it is routing
	protocol to decide, normally.  you may want to configure RT-A and RT-B
	to meet this requirement, read RFC3178 for more details.

> Other people are interested in the following situation:
> 
> Set of servers A has a public facing side, heavily firewalled, and a  
> private side. Set of servers B doesn't talk to the outside world, but  
> does talk to servers A on the private side so optimum safety is  
> accomplished without having firewalls etc on the private side for  
> cost/performance reasons.
> 
> I don't see how using public address space for the private  
> interconnection between the two sets of servers makes sense.

	if you have firewall device to begin with, there is no difference
	at all even if you pick a global address for B, or address with
	limited scope (site-local, ULA, whatever).  in fact, if you pick a
	global address it would be easier for A to handle traffic from B.

> > 	normal application which makes outgoing TCP connection DOES NOT
> > 	perform bind(2), so the application will only try all of the
> > 	destination addresses available on the DNS, not all the src/dst  pairs.
> 
> In shim6 I have spoken up to avoid pushing this functionality into  
> applications, but although the application is not the good place for  
> it, if it's not done elsewhere, it will have to be done in applications.
> 
> And smart implementers will create a layer that takes care of these  
> details. Annoying, yes. Necessary, absolutely.

	no please don't.  for god's sake.  we would need another 10 years to
	adapt software, include sendmail, ruby, python, postfix, procmail,
	you name it, to the new API.

> > 	so it would be better for us to provide connectivity to all of the
> > 	cases in the network setup,
> 
> And how exactly do you do that in a world where mobile devices roam  
> from network to network, often with overlap between two forms of  
> connectivity and connectivity going away without prior warning?

	i do not get what you mean.  more concrete example please?

> > 	think about it.  then why "site-local" was killed after a long long
> > 	debate?
> 
> Ambiguity.

	RFC3879 seems to have more reasons other than "Ambiguity".

> >         or do i
> > 	keep silence and see people go into the pitfall and injured?
> 
> If you know a better way, by all means...

	so i have been trying to...

itojun